In Rails 5 catches invalid UTF8 characters in querystring in a
params middleware, errors are handled by a params middleware and
raises a BadRequest exception. This means that these UTF8 errors
are not raised deeper in application stack and these can't also
be handled on application level.
If we would want to have custom handler for these errors, we would
have to create a new middleware and insert it before actionpack's
params middleware and rescue BadRequest exceptions there. But there
is no need to do this currently (see discussion on
https://gitlab.com/gitlab-org/gitlab-ce/issues/51908)
Was introduced in the time that GitLab still used NFS, which is not
required anymore in most cases. By removing this, the API it calls will
return empty responses. This interface has to be removed in the next
major release, expected to be 12.0.
By default, all sessions are given the same expiration time configured in the
session store (e.g. 1 week). However, unauthenticated users can generate a lot
of sessions, primarily for CSRF verification. It makes sense to reduce the TTL
for unauthenticated to something much lower than the default (e.g. 1 hour) to
limit Redis memory. In addition, Rails creates a new session after login,
so the short TTL doesn't even need to be extended.
Closes#48101
Since Rails 5.0 the `protect_from_forgery` callback doesn't run first by
default anymore. [1]
Instead it gets inserted into callbacks chain where callbacks get
called in order.
This commit forces the callback to run first.
[1]: 3979403781
The `errors/access_denied` page should not fail to render when no
message is provided.
When accessing something as a sessionless user, we should also display
the terms message if possible.
We have a number of import errors occurring with 422 errors, and
it's hard to determine why they are happening. This change will
surface the errors in the log lines.
Relates to #47365
When we want to show an access denied message to a user, we don't have
to hide the resource's existence.
So in that case we render a 403, this 403 is not handled by nginx on
omnibus installs, making sure the message is visible to the user.
Before we would block the `sign_out` request when the user did not
accept the terms, therefore redirecting them to the terms again.
By allowing all request to devise controllers, we avoid this problem.
This enforces the terms in the web application. These cases are
specced:
- Logging in: When terms are enforced, and a user logs in that has not
accepted the terms, they are presented with the screen. They get
directed to their customized root path afterwards.
- Signing up: After signing up, the first screen the user is presented
with the screen to accept the terms. After they accept they are
directed to the dashboard.
- While a session is active:
- For a GET: The user will be directed to the terms page first,
after they accept the terms, they will be directed to the page
they were going to
- For any other request: They are directed to the terms, after they
accept the terms, they are directed back to the page they came
from to retry the request. Any information entered would be
persisted in localstorage and available on the page.
Rails 5.0 requires to explicitly permit attributes when building a URL
using current `params` object.
The `safe_params` helper allows developers to just call `safe_params.merge(...)`
instead of manually adding `permit` to every call.
https://github.com/rails/rails/pull/20868
The default 404 handler would return the Content-Type format based on the
given format extension. This would cause the Rails CSRF protection to flag an
error, since the .js extension gets mapped to text/javascript format.
Closes#40771
Devise sets `current_user`, but not all controllers authenticate users by
session tokens. Try to use the controller-defined `authenticated_user` if
`current_user` is not available.
Closesgitlab-org/gitlab-ee#3611
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
A `performance_team` Flipper group has been created. By default this
group is nil but this can be customized in `gitlab.yml` via the
performance_bar.allowed_group setting.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Support noticed that a number of exceptions, such as
"Encoding::CompatibilityError (incompatible character encodings: UTF-8 and
ASCII-8BIT)", failed to report to Sentry. The `rescue_from` in the
ApplicationController prevented these exceptions from being recorded.
This change ensures that these exceptions are properly captured.
There was a race condition issue when the application was generating an
email and was using a language that was previously being used in other
request.
- 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
Resolves#24576
Modify the guard clause of the `ApplicationController#require_email`
before action to skip requests where an admin is impersonating the
current user.
We need this to prevent routing error when user access URL like /123
when there is no resource located under such name
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
When reading conflicts:
1. Add a `type` field. `text` works as before, and has `sections`;
`text-editor` is a file with ambiguous conflict markers that can only
be resolved in an editor.
2. Add a `content_path` field pointing to a JSON representation of the
file's content for a single file.
3. Hitting `content_path` returns a similar datastructure to the `file`,
but without the `content_path` and `sections` fields, and with a
`content` field containing the full contents of the file (with
conflict markers).
When writing conflicts:
1. Instead of `sections` being at the top level, they are now in a
`files` array. This matches the read format better.
2. The `files` array contains file hashes, each of which must contain:
a. `new_path`
b. `old_path`
c. EITHER `sections` (which works as before) or `content` (with the
full content of the resolved file).
Provide more sensible default sort order for issues and merge requests
based on the following table:
| type | state | default sort order |
|----------------|--------|--------------------|
| issues | open | last created |
| issues | closed | last updated |
| issues | all | last created |
| merge requests | open | last created |
| merge requests | merged | last updated |
| merge requests | closed | last updated |
| merge requests | all | last created |
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.
- 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
- To hold registrations from U2F devices, and to authenticate them.
- Previously, `User#two_factor_enabled` was aliased to the
`otp_required_for_login` column on `users`.
- This commit changes things a bit:
- `User#two_factor_enabled` is not a method anymore
- `User#two_factor_enabled?` checks both the
`otp_required_for_login` column, as well as `U2fRegistration`s
- Change all instances of `User#two_factor_enabled` to
`User#two_factor_enabled?`
- Add the `u2f` gem, and implement registration/authentication at the
model level.
Upgrade devise, devise-two-factor, and attr_encrypted
Devise 4 includes support for Rails 5, working towards #14286. devise-async doesn't support Devise 4.0 and in 4.1 the bug that was blocking using Devise's built-in ActiveJob integration was fixed. So devise-async is removed. devise-two-factor 3.0.0 is required for Devise 4 support.
attr_encrypted and encryptor are optional but recommended upgrades for devise-two-factor 3.0.0. The mode and algorithm will need to be changed in order to update to attr_encrypted 4.x in the future.
See merge request !4216
- Use `TokenAuthenticatable` to generate the personal access token
- Remove a check for `authenticity_token` in application controller;
this should've been `authentication_token`, maybe, and doesn't make
any sense now.
- Have the datepicker appear inline
- Rename the `authenticate_user_from_token!` filter to
`authenticate_user_from_private_token!`
- Add a new `authenticate_user_from_personal_access_token!` filter
- Add tests for both.
Currently there is no way to download a raw file without embedding
the token in the URL, which exposes the token in the URL. There
should be an way of sending this information via the header as the
API does.
Closes https://github.com/gitlabhq/gitlabhq/issues/8137
Sorting by "id" has the same effect as sorting by created_at while
performing far better and without the need of an extra index (in case
one wanted to speed up sorting by "created_at").
Sorting by "Recently updated" still uses the physical "updated_at"
column as there's no way to use the "id" column for this instead.
It was possible to create an infi redirect when the user set up the
`home_page_url` to redirect to the main URL of the gitlab instance.
This fix makes sure this redirect is not possible.
Fixes!1020
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
Safari 9.0 does not yet honor the HTML5 `origin-when-cross-origin` mode,
and it's possible load balancers/proxies strip the HTTP_REFERER from
the request header. In these cases, default to some default path.
Closes#3122
Closes https://github.com/gitlabhq/gitlabhq/issues/9731
Apply syntax highlighting to fenced code blocks client-side
Instead of applying the syntax highlighting scheme class to these blocks
server-side, we use Javascript and Gon to apply the user's color scheme
(or the default) client-side.
This will make it easier to cache these blocks in the future because
they're no longer state-dependent.
See merge request !1203
Many users naively set the home page URL setting to external_url
(e.g. https://mydomain.com). When an unauthenticated user signs in, this
causes endless redirections. For example, this is occuring:
1. Unauthenticated user attempts to access https://mydomain.com/dashboard
2. Application redirects to the home page URL: https://mydomain.com
3. Repeat step 2
In step 3, ApplicationController should have redirected the user to
https://mydomain.com/users/sign_in. Disabling the redirection if home
page URL is the same as external_url prevents users from messing up.
Closes https://github.com/gitlabhq/gitlabhq/issues/8843Closes#2057
Instead of rendering this value server-side, we use Javascript and Gon
to apply the user's color scheme (or the default) to any syntax
highlighted code blocks.
This will make it easier to cache these blocks in the future because
they're no longer state-dependent.
Redirection to the home page URL was broken by changing the target for
`root_url` from `DashboardController` to `RootController` in
94d3c1433d. This regression was introduced
in the 7.12.0 release.
Fixes#1916.