Use new auth in advanced wiki search

Terri Churequested to merge
491216-use-new-auth-filter-in-wikis into master

What does this MR do and why?

This code introduces a new feature flag called search_advanced_wiki_new_auth_filter that changes how GitLab handles permissions when searching through wiki pages.

The main change switches from an older authorization system to a newer one that uses project IDs and traversal IDs to determine what wiki content users can access. When the feature flag is enabled, the system uses the new authorization method; when disabled, it falls back to the legacy approach.

The code also includes extensive tests to ensure both the new and old authorization systems work correctly across different scenarios - testing various user permission levels (admin, reporter, guest, etc.) and project visibility settings (public, internal, private) for both project wikis and group wikis.

Additionally, several test files were updated to make projects public by default and to properly pass search options, ensuring the tests work correctly with the new authorization system. The changes maintain backward compatibility by keeping the old system available when the feature flag is turned off.

References

Screenshots or screen recordings

Before After

How to set up and validate locally

Wiki searches using advanced search are covered by extensive permission/visibility specs in ee/spec/services/ee/search/

This code is used by advanced search for wikis searches. So to test it out, you'll need to:

  • enable elasticsearch in gdk
  • enable advanced search (in Admin - Settings - Search - Advanced search) in the instance
  • index the instance
  • create group and project wikis in different groups and projects (with public and private visibility levels)
  • login with a non-admin user (you could also test with admin, anonymous, user without authoriation)
  • perform searches for global, group, and project wikis

To test the specific bug mentioned in the related issue:

  1. create two top level groups with private visibility (group A and group B)
  2. in group A:
  • create a group level wiki
  • give group B guest access to the group
  1. login with a user from group B
  2. run group and global wiki searches
  3. make sure you get results back from group A

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Terri Chu

Merge request reports