We need to preload the ancestors of search results after applying
pagination limits. This way the search results itself are paginated,
but not the ancestors.
If we don't do this, we might not preload a parent group of a search
result as it has been cut off by pagination.
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.
If you upload a file with a .js extension, Rails' cross-origin JavaScript
protection will prevent a user from downloading the file with a 422 error.
Setting the content-type to `text/plain` will allow the user to download
the file as a plaintext file.
Closes#45826
`InternalRedirect` prevents Open redirect issues by only allowing
redirection to paths on the same host.
It cleans up any unwanted strings from the path that could point to
another host (fe. //about.gitlab.com/hello). While preserving the
querystring and fragment of the uri.
It is already used by:
- `TermsController`
- `ContinueParams`
- `ImportsController`
- `ForksController`
- `SessionsController`: Only for verifying the host in CE. EE allows
redirecting to a different instance using Geo.
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.
By extracting a new `filter_items` method, we can override that in the
IssuesFinder and MergeRequestsFinder separately, so we don't need checks that
the model is the correct one, because we can just use the class we're in to know
that.
We can do the same for the VALID_PARAMS constant, by making it a class method.
This changes the issue and MR index pages so the pagination system
re-uses the output of the COUNT(*) query used to calculate the number of
rows per state (opened, closed, etc). This removes the need for an
additional COUNT(*) on both pages.
