| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Closes #2335
|
| |\ |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |\ |
|
| | | |
|
| |\ \
| |/
| |
| | |
backup-archive-permissions
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Set OmniAuth full_host parameter to ensure redirect URIs are correct
### What does this MR do?
This MR sets the OmniAuth `full_host` parameter to the configured GitLab URL to ensure the `redirect_uri` parameter is called with the right GitLab host.
### Why was this MR needed?
[OmniAuth attempts to grab the request URI](http://awesomeprogrammer.com/blog/2012/12/09/dealing-with-omniauth-redirect-uri-mismatch-invalid-port-number-gotcha/) and use that. If you set up a reverse proxy that terminates SSL at the Web server layer (e.g. https://gitlab.domain.com), omniauth will use the internal URL (e.g. http://my-host:8080) in its redirect URI unless all the Web server headers are properly set (e.g. `X-Forwarded-Port`, etc.). This is easy to forget or mess up, and it's better to ensure that OmniAuth has the right value from the start.
### What are the relevant issue numbers?
Closes #1967
See merge request !991
|
| | | |
| | |
| | |
| | | |
Closes #1967
|
| | |/
| |
| |
| |
| |
| | |
after sign-in
Closes #1612
|
| |/
|
|
|
| |
This change helps system administrators who want to replicate
GitLab backup files without needing root permissions.
|
| |
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Now we can simply loop through all themes, among other things.
This also removes the `dark_theme` / `light_theme` classes and the
`theme_type` helper, since they weren't used anywhere.
|
| |
|
|
| |
Closes #1798
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add session expiration delay configuration through UI application
Setting is accessible by the administrator through the UI and defaults to 1 week (the current setting)
Answers the following suggestions:
* http://feedback.gitlab.com/forums/176466-general/suggestions/6210719-make-session-length-configurable
* http://feedback.gitlab.com/forums/176466-general/suggestions/6730512-automatic-logout-after-a-time-being-idle
See merge request !774
|
| | |
| |
| |
| |
| | |
delay is in seconds
more legible code in session_store
Added `GitLab restart required` help block to session_expire_delay
|
| | |
| |
| | |
settings
|
| | |
| |
| |
| | |
omnibus-gitlab.
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, a user needed to first sign in with his LDAP identity and then manually
link his/her account with an omniauth identity from their profile.
Only when this is done can the user authenticate with the omniauth provider and at
the same time benefit from the LDAP integration (HTTPS authentication with LDAP
username/password and in EE: LDAP groups, SSH keys etc.).
This feature automates the process by looking up a corresponding LDAP person when a
user connects with omniauth for the first time and then automatically linking the LDAP
and omniauth identities (of course, like the existing allow_single_sign_on setting,
this is meant to be used with trusted omniauth providers).
The result is identical to a manual account link.
Add config initializers for other omniauth settings.
|
| |
|
|
|
|
|
| |
showing the GitLab sign-in page
This is useful when integrating with existing SSO environments and we want to use a single Omniauth provider for
all user authentication.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Protect OmniAuth request phase against CSRF.
Addresses #2268.
See merge request !1793
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use task_list gem for task lists
Task Lists can now be used in comments, and they'll render in previews. :clap:
Closes internal https://dev.gitlab.org/gitlab/gitlabhq/issues/2271
See merge request !599
|
| | | | |
|
| |/ / |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add application setting to restrict user signups to e-mail domains
This feature was requested long ago:
http://feedback.gitlab.com/forums/176466-general/suggestions/4118466-ability-to-register-only-from-ceratain-domains
This MR is based off !253 but changed to use application settings and use wildcard strings
to give more flexibility in pattern matching. Regexps seemed overkill and prone to mistakes.
Also note that validation is ONLY done on creation to prevent breaking existing users who do not have a whitelisted domain. However, this allows a user to sign-up and change his/her email to a non-whitelisted domain.
Screenshots:
See merge request !598
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This feature was requested long ago:
http://feedback.gitlab.com/forums/176466-general/suggestions/4118466-ability-to-register-only-from-ceratain-domains
This MR is based off !253 but changed to use application settings and use wildcard strings
to give more flexibility in pattern matching. Regexps seemed overkill and easy to get wrong.
Only restrict e-mail addresses upon creation
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
sent through Devise
Fix test case that was passing due to a broken `around` statement.
Closes #1556
|
| |/ |
|
| |
|
|
| |
Fixes #2266
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
