`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.
Direct disk access is done through Gitaly now, so the legacy path was
deprecated. This path was used in Gitlab::Shell however. This required
the refactoring in this commit.
Added is the removal of direct path access on the project model, as that
lookup wasn't needed anymore is most cases.
Closes https://gitlab.com/gitlab-org/gitaly/issues/1111
There are 2 problems with this spec:
1. It checks for default visiblity level however there is not code in
controller to handle such default. Same check can be performed on model
directly.
2. It passes empty application_setting hash while controller requires
application_setting not to be empty by using `require` with `permit`
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
This could only be possible for users that can create merge requests
within a project.
So they need to be a allowed to create a branch and create a merge request.
Repository archives are always named `<project>-<ref>-<sha>` even if
the ref is a commit. A consequence of always including the sha even
for tags is that packaging a release is more difficult because both
the ref and sha must be known by the packager.
- add `<project>/-/archive/<ref>/<filename>.<format>` route using the
`-` separator to prevent namespace collisions. If the filename is
`<project>-<ref>` or the ref is a sha, the sha will be omitted,
otherwise the default filename will be used.
- deprecate previous archive route `repository/<ref>/archive`
Using strong params to require the presence of a username when calling
`update_username`. Otherwise we'd raise a `NoMethodError` validating
the paths on disk.
When listing issues and merge requests on dasboard page,
make sure that at least one filter is enabled.
User's id is used in search autocomplete widget instead
of username, which allows presetting user in filter dropdowns.
Related to #43246