- 07 Apr, 2018 4 commits
-
-
Kamil Trzciński authored
-
Mayra Cabrera authored
- Remove extra method for authorize_admin_project - Ensure project presence - Rename 'read_repo' to 'read_repository' to be more verbose
-
Mayra Cabrera authored
- 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
-
Mayra Cabrera authored
This will allow to download a repo using the token from the DeployToken
-
- 27 Mar, 2018 1 commit
-
-
Horatiu Eugen Vlad authored
-
- 05 Mar, 2018 1 commit
-
-
Horatiu Eugen Vlad authored
-
- 28 Feb, 2018 1 commit
-
-
Horatiu Eugen Vlad authored
-
- 02 Feb, 2018 1 commit
-
-
Mario de la Ossa authored
-
- 23 Nov, 2017 2 commits
-
-
Douwe Maan authored
-
Markus Koller authored
-
- 17 Nov, 2017 2 commits
-
-
Michael Kozono authored
-
Michael Kozono authored
-
- 08 Nov, 2017 1 commit
-
-
Stan Hu authored
-
- 02 Nov, 2017 2 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
- 18 Sep, 2017 1 commit
-
-
Robin Bobbitt authored
Closes #37789
-
- 01 Sep, 2017 1 commit
-
-
Tiago Botelho authored
-
- 31 Aug, 2017 1 commit
-
-
Sean McGivern authored
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.
-
- 21 Aug, 2017 1 commit
-
-
Robin Bobbitt authored
-
- 14 Aug, 2017 1 commit
-
-
Robert Speicher authored
An upcoming update to rubocop-gitlab-security added additional violations.
-
- 02 Aug, 2017 1 commit
-
-
Lin Jen-Shin authored
full_authentication_abilities. This is fine because we're going to check with can?(..) anyway
-
- 13 Jul, 2017 1 commit
-
-
Robin Bobbitt authored
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
-
- 30 Jun, 2017 1 commit
-
-
Timothy Andrew authored
- There's no need to use `API::Scope` for scopes that don't have `if` conditions, such as in `lib/gitlab/auth.rb`.
-
- 29 Jun, 2017 1 commit
-
-
Timothy Andrew authored
- To represent an authorization scope, such as `api` or `read_user` - This is a better abstraction than the hash we were previously using.
-
- 28 Jun, 2017 2 commits
-
-
Timothy Andrew authored
- 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`.
-
Timothy Andrew authored
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
-
- 08 Jun, 2017 1 commit
-
-
Robin Bobbitt authored
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.
-
- 06 Jun, 2017 1 commit
-
-
Z.J. van de Weg authored
-
- 05 Jun, 2017 1 commit
-
-
Z.J. van de Weg authored
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. Fixes gitlab-org/gitlab-ce#19219
-
- 21 May, 2017 1 commit
-
-
Horatiu Eugen Vlad authored
Fixes #32598
-
- 13 Apr, 2017 1 commit
-
-
Timothy Andrew authored
- 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
-
- 07 Mar, 2017 4 commits
-
-
Markus Koller authored
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.
-
Markus Koller authored
-
Markus Koller authored
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.
-
Markus Koller authored
-
- 06 Mar, 2017 4 commits
-
-
Tiago Botelho authored
-
Pawel Chojnacki authored
- 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
-
Pawel Chojnacki authored
-
Pawel Chojnacki authored
-
- 01 Mar, 2017 1 commit
-
-
Sean McGivern authored
-