Anonymous Search Access Issue After Upgrade to GitLab 18.0

Summary

After upgrading to GitLab 18.0, anonymous users are being redirected to the sign-in page when attempting to access search functionality, despite the setting anonymous_searches_allowed being intended to default to true. This represents a regression in behavior compared to previous versions where anonymous search was enabled by default.

Steps to reproduce

  1. Install GitLab EE version 17.11.0-ee.0 using Docker:
docker run --detach \
  --hostname localhost \
  --publish 80:80 \
  --name gitlab \
  --restart always \
  --volume ~/gitlab/config:/etc/gitlab \
  --volume ~/gitlab/logs:/var/log/gitlab \
  --volume ~/gitlab/data:/var/opt/gitlab \
  gitlab/gitlab-ee:17.11.0-ee.0
  1. Verify that anonymous search works as expected:
curl -I --request GET --url 'http://localhost/search?scope=projects&search=Public%20Project'
# Returns 200 OK
  1. Upgrade to GitLab 18.0 (nightly):
docker stop gitlab
docker rm gitlab
docker run --detach \
  --hostname localhost \
  --publish 80:80 \
  --name gitlab \
  --restart always \
  --volume ~/gitlab/config:/etc/gitlab \
  --volume ~/gitlab/logs:/var/log/gitlab \
  --volume ~/gitlab/data:/var/opt/gitlab \
  gitlab/gitlab-ee:nightly
  1. Attempt anonymous search:
curl -I --request GET --url 'http://localhost/search?scope=projects&search=Public%20Project'
# Returns 302 Found with Location: http://localhost/users/sign_in
  1. Check the anonymous_searches_allowed setting:
docker exec -it gitlab gitlab-rails console
irb(main):001> ApplicationSetting.last[:anonymous_searches_allowed]
=> false  # This should be true by default after the upgrade

Example Project

This issue occurs on any GitLab installation that is upgraded from version 17.11 to 18.0. It affects all search functionality for unauthenticated users.

What is the current bug behavior?

After upgrading from GitLab 17.11 to 18.0, the anonymous_searches_allowed setting defaults to false, causing all anonymous search requests to be redirected to the sign-in page with a 302 status code.

What is the expected correct behavior?

As stated in the related MR (gitlab-org/gitlab!190090), anonymous search should remain enabled by default. The anonymous_searches_allowed setting should default to true to maintain backward compatibility with the previous feature flag allow_anonymous_searches which was enabled by default.

Relevant logs and/or screenshots

The issue is evident from a curl request showing redirection:

curl -I --request GET --url 'http://localhost/search?scope=projects&search=Public%20Project'
HTTP/1.1 302 Found
Server: nginx
Date: Fri, 09 May 2025 10:24:48 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Cache-Control: no-cache
Content-Security-Policy:
Location: http://localhost/users/sign_in
Nel: {"max_age": 0}
Set-Cookie: _gitlab_session=73daa81012b5edfef199c96eb227b770; path=/; HttpOnly
X-Gitlab-Meta: {"correlation_id":"01JTT9713ER1EHC2QTA7CX5PKK","version":"1"}
X-Request-Id: 01JTT9713ER1EHC2QTA7CX5PKK
X-Runtime: 0.076301
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

Rails console verification showing the incorrect default value:

irb(main):001> ApplicationSetting.last[:anonymous_searches_allowed]
=> false

Additional note - on a fresh install search is working as expected and setting is true

docker run --detach \
  --hostname localhost \
  --publish 80:80 \
  --name gitlab \
  --restart always \
  gitlab/gitlab-ee:nightly
67f09c505b6d10516398e7cc69d4d25dea06e1cd567858b535bc70c61623f2cf

...

 Ruby:         ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x86_64-linux]
 GitLab:       18.0.0-pre (52cee9832f9) EE
 GitLab Shell: 14.41.0
 PostgreSQL:   16.8
------------------------------------------------------------[ booted in 57.27s ]
Loading production environment (Rails 7.1.5.1)
irb(main):001> ApplicationSetting.last[:anonymous_searches_allowed]
=> true

Related information

  • Related MR: !190090 (merged)
  • Issue reference: gitlab-com/gl-infra/software-delivery/framework/software-delivery-framework-issue-tracker#84