If the request wasn't initiated by gitlab we shouldn't add the new
identity to the user, and instead show that we weren't able to link
the identity to the user.
This should fix: https://gitlab.com/gitlab-org/gitlab-ce/issues/56509
It consists of two parts:
1. Redirecting users to the configured external storage
1. Allowing the external storage to request the static object(s)
on behalf of the user by means of specific tokens
Part of https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6829
This was shown in specs but surely this will be happening in application
code as well if this method is passes a frozen string.
We were also trying to force_encode a OmniAuth::AuthHash which had the
very confusing behaviour of returning nil when it was sent a method that
it did not define. Fix that by only force_encoding a String.
We've previously exposed ca_file and ssl_version but there are many
possible options that can be used inside tls_options. Instead of
exposing individual ones, simply expose the entire hash so it can
be passed in and we won't have to add things in the future.
As mentioned in
https://gitlab.com/gitlab-org/gitlab-ee/issues/9035#note_129093444,
Rails 5 switched ActionDispatch::Request so that it no longer inherits
Rack::Request directly. A middleware that uses Rack::Request to
read the environment may see stale request parameters if
another middleware modifies the environment via ActionDispatch::Request.
To be safe, we should be using ActionDispatch::Request everywhere.
Adds gitlab.impersonation_enabled config option defaulting to true to
keep the current default behaviour.
Only the act of impersonation is modified, impersonation token
management is not affected.
[master] Resolve "Personal access token with only `read_user` scope can be used to authenticate any web request"
See merge request gitlab/gitlabhq!2583
Due to a regression in !20608, the LDAP authenticator was not being used
unless OmniAuth was enabled. This change allows the LDAP provider to be used
if it is configured regardless of the OmniAuth setting.
Closes#50579
One of the spec files sets `nil` value for env varialbe
`action_dispatch.request.formats`. Rather than setting `nil` value,
we can delete the `action_dispatch.request.formats` key from `env`
(which should be closer to real use case anyway). The reason is that
in Rails 5, `formats` method does not set default array of formats
if the env key is already set (even if set to `nil`).
This will make it clearer to users which account is being used to make
the API/git call. So they know which account needs to be used to
accept the terms.
Closes#46649
An LDAP sign-in request results in a different request parameter than
a standard GitLab sign-in. Since Warden doesn't pass us the user that
was blocked, we first search for a `username` in the request parameters
and then look for `user.login`.
Closes#46307
When terms are enforced, but the user has not accepted the terms
access to the API & git is rejected with a message directing the user
to the web app to accept the terms.
The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.
To fix this:
1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
`Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
like that in several places.
3. Change the initializers to use that new form.
- cleanup formating in haml
- clarify time window is in seconds
- cleanup straneous chunks in db/schema
- rename count_uniqe_ips to update_and_return_ips_count
- other