- When using 'read_repo' password and project are sent, so we used both
of them to fetch for the token
- When using 'read_registry' only the password is sent, so we only use
that for fetching the token
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.
When sign-in is disabled:
- skip password expiration checks
- prevent password reset requests
- don’t show Password tab in User Settings
- don’t allow login with username/password for Git over HTTP requests
- render 404 on requests to Profiles::PasswordsController
- Use a struct for scopes, so we can call `scope.if` instead of `scope[:if]`
- Refactor the "remove scopes whose :if condition returns false" logic to use a
`select` rather than a `reject`.
1. Get the spec for `lib/gitlab/auth.rb` passing.
- Make the `request` argument to `AccessTokenValidationService` optional -
`auth.rb` doesn't need to pass in a request.
- Pass in scopes in the format `[{ name: 'api' }]` rather than `['api']`, which
is what `AccessTokenValidationService` now expects.
2. Get the spec for `API::V3::Users` passing
2. Get the spec for `AccessTokenValidationService` passing
If internal auth is disabled and LDAP is not configured on the instance,
present the user with a message to create a personal access token if his
Git over HTTP auth attempt fails.
This is the first commit doing mainly 3 things:
1. create a new scope and allow users to use it
2. Have the JWTController respond correctly on this
3. Updates documentation to suggest usage of PATs
There is one gotcha, there will be no support for impersonation tokens, as this
seems not needed.
Fixesgitlab-org/gitlab-ce#19219
- We currently support fetching code with username = 'oauth2' and
password = <access_token>.
- Trying to _push_ code with the same credentials fails with an authentication
error.
- There's no reason this shouldn't be enabled, especially since we allow the
OAuth client to create deploy keys with push access:
https://docs.gitlab.com/ce/api/deploy_keys.html#add-deploy-key
Gitlab::Auth and API::APIGuard already check for at least one valid
scope on personal access tokens, so if the scopes are empty the token
will always fail validation.
Gitlab::Auth.find_with_user_password is currently used in these places:
- resource_owner_from_credentials in config/initializers/doorkeeper.rb,
which is used for the OAuth Resource Owner Password Credentials flow
- the /session API call in lib/api/session.rb, which is used to reveal
the user's current authentication_token
In both cases users should only be authenticated if they're in the
active state.
- 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
We accept half a dozen different authentication mechanisms for
Git over HTTP. Fairly high in the list we were checking user
password, which would also query LDAP. In the case of LFS,
OAuth tokens or personal access tokens, we were unnecessarily
hitting LDAP when the authentication will not succeed. This
was causing some LDAP/AD systems to lock the account. Now,
user password authentication is the last mechanism tried since
it's the most expensive.
- Previously, AccessTokenValidationService was a module, and all its public
methods accepted a token. It makes sense to convert it to a class which accepts
a token during initialization.
- Also rename the `sufficient_scope?` method to `include_any_scope?`
- Based on feedback from @rymai
- Mainly whitespace changes.
- Require the migration adding the `scope` column to the
`personal_access_tokens` table to have downtime, since API calls will
fail if the new code is in place, but the migration hasn't run.
- Minor refactoring - load `@scopes` in a `before_action`, since we're
doing it in three different places.
- Move the `Oauth2::AccessTokenValidationService` class to
`AccessTokenValidationService`, since it is now being used for
personal access token validation as well.
- Each API endpoint declares the scopes it accepts (if any). Currently,
the top level API module declares the `api` scope, and the `Users` API
module declares the `read_user` scope (for GET requests).
- Move the `find_user_by_private_token` from the API `Helpers` module to
the `APIGuard` module, to avoid littering `Helpers` with more
auth-related methods to support `find_user_by_private_token`
“Can create groups” and “Can create teams” had hardcoded defaults to
`true`. Sometimes it is desirable to prohibit these for newly created
users by default.
Should no longer freak out when omniauth settings aren't present in
gitlab.yml. People who aren't using it shouldn't even have to put a
'false' entry in their config for it (and probably wouldn't, after an
upgrade).
Mayra Cabrera
Kamil Trzciński
Horatiu Eugen Vlad
Mario de la Ossa
Sean McGivern
Douwe Maan
Markus Koller
Stan Hu
Robin Bobbitt
Douwe Maan
Tiago Botelho
Sean McGivern
Robert Speicher
Lin Jen-Shin
Timothy Andrew
Z.J. van de Weg
Pawel Chojnacki
Simon Vocella
Drew Blessing
Patricio Cano
Jacob Vosmaer
Jacob Vosmaer
Andrey Krivko
Jan-Willem van der Meer
skv
Dmitriy Zaporozhets
Izaak Alpert
Dmitry Medvinsky
Andrey Kumanyaev
Andrew8xx8
Riyad Preukschas
Godric
Maxim Filatov
Nihad Abbasov