Exclude requesters from Project#members, Group#members and User#members
## What does this MR do?
It excludes requesters from the `Project#members`, `Group#members` and `User#members` associations, and adds new `Project#requesters` and `Group#requesters` associations.
## Are there points in the code the reviewer needs to double check?
No.
## Why was this MR needed?
Without this, if you call `project.members`, requesters are included in the results! This is at best misleading, and at worst can lead to security issues. By excluding requesters from the `#members` associations, we avoid introducing security inadvertently since you have to call the `#requesters` association explicitly to get requesters.
## What are the relevant issue numbers?
This is something I realized while fixing the security issue #19102.
## Does this MR meet the acceptance criteria?
- [x] I don't think this needs a CHANGELOG since this is an internal change
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !4946
The issue was that @notes were not passed to Banzai::NoteRenderer.render
in Projects::SnippetsController#show. This was forgotten in d470f3d1.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Admin should be able to turn shared runners into specific ones:
## What does this MR do?
Make sure admins could turn shared runners into specific runners.
## Are there points in the code the reviewer needs to double check?
Is this the desired behaviour?
## Why was this MR needed?
Closes#19039Closes#19272
See merge request !4961
* upstream/master: (120 commits)
Update CHANGELOG for 8.9.4, 8.8.7, and 8.7.9.
Remove additional entries from CHANGELOG
Catch permission denied errors and ignore the disk
Remove coveralls lines
Make GH one-off auth the default again for importing GH projects
Import from Github using Personal Access Tokens.
Remove hardcoded gitlab-shell version in test env now that the required tag is published
Updated breakpoint for sidebar pinning
Expire branch/tag git data when needed.
Remove unnecessary parens
Enable Style/UnneededCapitalW Rubocop cop
Expiry date on pinned nav cookie
Fix broken spec in git_push_service_spec by stubbing an external issue tracker
Handle external issues in IssueReferenceFilter
Move Changelog entry for build retry fix to 8.9.4
Add Changelog entry for build sidebar retry link fix
Improve method that tells if build is retryable
Do not show build retry link when build is active
Remove coveralls as its unused
Move changelot item "Add sub nav to file page view" to 8.9.4
...
This stands as an alternative to using OAuth to access a user's Github
repositories. This is setup in such a way that it can be used without OAuth
configuration.
From a UI perspective, the how to import modal has been replaced by a full
page, which includes a form for posting a personal access token back to the
Import::GithubController.
If the user has logged in via GitHub, skip the Personal Access Token and go
directly to Github for an access token via OAuth.
The regression was introduced by:
https://gitlab.com/gitlab-org/gitlab-ce/commit/1b8f52d9206bdf19c0dde04505c4c0b1cf46cfbe
I did that because there's a test specifying that a shared runner cannot
be enabled, in the API. So I assume that is the case for non-admin, but
admins should be able to do so anyway.
Also added a test to make sure this won't regress again.
Closes#19039
Fix an information disclosure when requesting access to a group containing private projects
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/19102.
The commit speaks for itself:
Fix an information disclosure when requesting access to a group containing private projects
The issue was with the `User#groups` and `User#projects` associations
which goes through the `User#group_members` and `User#project_members`.
Initially I chose to use a secure approach by storing the requester's
user ID in `Member#created_by_id` instead of `Member#user_id` because I
was aware that there was a security risk since I didn't know the
codebase well enough.
Then during the review, we decided to change that and directly store the
requester's user ID into `Member#user_id` (for the sake of simplifying
the code I believe), meaning that every `group_members` / `project_members`
association would include the requesters by default...
My bad for not checking that all the `group_members` / `project_members`
associations and the ones that go through them (e.g. `Group#users` and
`Project#users`) were made safe with the `where(requested_at: nil)` /
`where(members: { requested_at: nil })` scopes.
Now they are all secure.
See merge request !1973
The issue was that `MergeRequest#mergeable?` returns false when the CI
state is not success and project.only_allow_merge_if_build_succeeds is
true. In this case `Projects::MergeRequestsController#merge` would
return the `:failed` status when enabling `merge_when_build_succeeds`,
thus leading to a weird state and the MR never automatically merged.
The fix is to disable the CI state check in the controller safeguard
that early return the `:failed` status.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Fix temp file being deleted after the request while importing a GitLab project
Fixes https://gitlab.com/gitlab-com/infrastructure/issues/151
In production, the temporary uploaded file is getting deleted straight after the request so the Sidekiq worker is unable to find it in `/tmp`
Also, improved erroring/logging of this situation.
See merge request !4894
The issue was with the `User#groups` and `User#projects` associations
which goes through the `User#group_members` and `User#project_members`.
Initially I chose to use a secure approach by storing the requester's
user ID in `Member#created_by_id` instead of `Member#user_id` because I
was aware that there was a security risk since I didn't know the
codebase well enough.
Then during the review, we decided to change that and directly store the
requester's user ID into `Member#user_id` (for the sake of simplifying
the code I believe), meaning that every `group_members` / `project_members`
association would include the requesters by default...
My bad for not checking that all the `group_members` / `project_members`
associations and the ones that go through them (e.g. `Group#users` and
`Project#users`) were made safe with the `where(requested_at: nil)` /
`where(members: { requested_at: nil })` scopes.
Now they are all secure.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Douwe Maan
Patricio Cano
Douwe Maan
Grzegorz Bizon
Rémy Coutable
Yorick Peterse
Jacob Vosmaer
Lin Jen-Shin
Josh Frye
Eric K IdemaandRémy Coutable
Dmitriy Zaporozhets
Alejandro Rodríguez
Robert Speicher
Paco Guzman
Felipe Artur
Z.J. van de Weg
Robert Speicher
Stan Hu
Ruben Davila