Explore project list is not organization-scoped: ProjectsFinder receives the wrong params key
Problem
Explore::ProjectsController#load_projects (app/controllers/explore/projects_controller.rb)
builds finder params using the key current_organization:. ProjectsFinder#by_organization
(app/finders/projects_finder.rb:315) reads params[:organization]. Neither
ProjectsFinder nor EE::ProjectsFinder (ee/app/finders/ee/projects_finder.rb) reads
:current_organization, so the key is inert and the organization filter never applies to
Explore's project listing.
Concrete symptom: GET /explore/projects/topic/<topic_name> resolves the topic within the
current organization, then lists projects carrying that topic from every organization. The
page is internally inconsistent.
Impact
A self-managed instance with multiple organizations would see other organizations' public projects in Explore. This is not a security vulnerability but a misleading behavior.
User-visible impact on GitLab.com today is probably small, because the organizations rollout is partial. In production, ui_for_organizations and organization_switching are enabled but not globally, and root_group_organization_backfill — the flag that would move root groups out of the default organization — does not exist at all. Most projects are therefore expected to still belong to the default organization, though the actual distribution of projects.organization_id is worth confirming with group::organizations.
Proposed fix
Rename the key from current_organization: to organization: in load_projects, and add a
regression spec to spec/controllers/explore/projects_controller_spec.rb asserting that
GET #topic excludes projects outside the current organization.
Implemented in !251487 (merged).
References
- Raised by
@rymaias a non-blocking review comment on !246815 (merged), during a RuboCopRails/StrongParamsaudit enumerating which keys reachProjectsFinder. Not fixed inline there because a key rename is a behavior change, not a refactor. - Fix MR: !251487 (merged)