| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This reverts commit 68e40bd49fde7b790bb31b9ac85a249bedd817d2, reversing
changes made to 2d1f823b4c8b60cee525384cb52e547d2be8925a.
|
| |
|
|
|
| |
This reverts commit 5e9666880376b3f53edb95cba77b5642d3cc1810, reversing
changes made to b35378a938e22f745b6c6ea32b53cb50f9b6c627.
|
| |\ |
|
| | | |
|
| |\ \
| |/
|/|
| | |
'origin/personal_access_token_api_and_impersonation_token'
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
in Profiles::NotificationsController#update
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Resolve "Add a doorkeeper scope suitable for authentication"
## What does this MR do?
- Add a single new scope (in addition to the `api` scope we've had) - `read_user`
- Allow creating OAuth applications and Personal access tokens with a scope selected
- Enforce scopes in the API
## What are the relevant issue numbers?
- Closes #20492
- EE counterpart for this MR: gitlab-org/gitlab-ee!946
See merge request !5951
|
| | | |
|
| |/
|
|
|
|
|
|
| |
The two factor authentication account string only had the user's
email address. This led to ambiguous entries in two factor
code generating apps. This adds the GitLab host to the account
string in the standard format (according to Google). No matter
the code generator this change disambiguates the entry.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Flushing the events cache worked by updating a recent number of rows in
the "events" table. This has the result that on PostgreSQL a lot of dead
tuples are produced on a regular basis. This in turn means that
PostgreSQL will spend considerable amounts of time vacuuming this table.
This in turn can lead to an increase of database load.
For GitLab.com we measured the impact of not using events caching and
found no measurable increase in response timings. Meanwhile not flushing
the events cache lead to the "events" table having no more dead tuples
as now rows are only inserted into this table.
As a result of this we are hereby removing events caching as it does not
appear to help and only increases database load.
For more information see the following comment:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6578#note_18864037
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
them [ci skip]
|
| |
|
|
|
|
|
|
| |
1. Remove an unnecessary (since we're fetching all the records anyway)
`pluck` while fetching U2F registration records.
2. Align "Your device was successfully set up!" section with the "U2F
Devices" table below.
|
| |
|
|
|
|
|
|
| |
1. Display a list of U2F devices on the `two_factor_auth` page.
2. Allow deleting individual U2F devices.
3. Allow setting a (optional) name for a device (during registration).
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
1. Only on supported Chrome versions
2. Mainly, this lets us simplify the javascript-based U2F check to
`window.u2f`, where `window.u2f` can either be loaded from the GitLab
server (for Chrome) or from the Firefox extension.
3. This is a better way to provide browser detection for U2F.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implement custom notification level options
part of #12758
See merge request !4389
|
| | |\ |
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | | |
Disable the unlink feature for SAML connected accounts (social login).
This disables the ability to manually unlink your SAML account, if you have one connected. In certain scenarios, the only allowed login mechanism can be SAML, and if you unlink your account you will be locked out of the system (configuration dependent).
Fixes #18613
See merge request !4662
|
| | |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Extract a duplicated `redirect_to`
- Fix a typo: "token", not "certificate"
- Have the "Expires at" datepicker be attached to a text field, not inline
- Have both private tokens and personal access tokens verified in a
single "authenticate_from_private_token" method, both in the
application and API. Move relevant logic to
`User#find_by_personal_access_token`
- Remove unnecessary constants relating to API auth. We don't need a
separate constant for personal access tokens since the param is the
same as for private tokens.
|
| |\ \
| |/ |
|
| | | |
|
| | | |
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Move the `TwoFactorAuthsController`'s `new` action to `show`, since
the page is not used to create a single "two factor auth" anymore. We
can have a single 2FA authenticator app, along with any number of U2F
devices, in any combination, so the page will be accessed after the
first "two factor auth" is created.
- Add the `u2f` javascript library, which provides an API to the
browser's U2F implementation.
- Add tests for the JS components
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- No hardcoded colors in any SCSS file except `variables.scss`
- Don't allow choosing a date in the past
- Use the same table as in the "Applications" tab
- The button should say "Create Personal Access Token"
- Float the revoke button to the right of the table cell
- Change the revocation message to be more explicit.
- Date shouldn't look selected on page load
- Don't use a panel for the created token
- Use a normal flash for "Your new personal access token has been created"
- Show the input (with the token) below it full width.
- Put the "Make sure you save it - you won't be able to access it again." message near the input
- Have the created token's input highlight all on single click
|
| |\ \
| |/ |
|
| | |\
| | |
| | |
| | | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | | |
| | |
| | |
| | |
| | | |
`render nothing: true` has been deprecated.
For more information see [pr](https://github.com/rails/rails/pull/20336)
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Use the `:personal_access_token` param root instead of
`personal_access_token_params`, because we aren't using the
`personal_access_token` param for authentication anymore (we're using
`private_token` instead).
- Use `build` to instantiate a `PersonalAccessToken`
- Use better-formatted dates
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Can't use `personal_access_token` anymore, because the contents
of that param are assumed to be a token string, and authenticated
against.
|
