Geo: Redirect after authentication prevents access to secondary

Summary

The setup is simply two nodes: primary and secondary.

When authenticating on the primary or secondary the unprivileged user is unable to access the secondary. Any attempt to access the secondary redirects to the primary. The only known way to reach the secondary is to login as an administrative user on the primary, navigate to the Geo admin panel and click the "Open Projects" button for the secondary.

The GitLab instance uses Okta for authentication and this may be related.

This bug prevents a customer from using Geo for anything but disaster recovery, as no unprivileged user can access the secondary node.

Steps to reproduce

  1. Log into the primary node and open a session in your browser.
  2. Open another browser tab and type in the address to the secondary
  3. The browser tab which was used to access the secondary is automatically redirected to the primary. This can be observed by inspecting the URL. As a regular user it is not possible to access the secondary due to this redirect loop.

It is possible to access the secondary if a user has admin privileges. In this case, a user can navigate to the Admin Area -> Geo -> Open projects (for the secondary) button and move from there to the secondary. No redirect is triggered. Occasionally, a notification is displayed on the secondary that the user is not logged in.

Example Project

N/A

What is the current bug behavior?

A redirect loop from secondary to primary that prevents users from accessing the secondary node.

What is the expected correct behavior?

A login attempt on the secondary results in a user being logged in to the secondary node.

Relevant logs and/or screenshots

Geo configuration from customer:

external_url 'removed'
gitlab_rails['lfs_enabled'] = true
gitlab_rails['lfs_storage_path'] = "/var/opt/gitlab/gitlab-rails/shared/lfs-objects"
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
git_data_dirs({
"default" => {
"path" => "/var/opt/gitlab/git-data"
}
})
gitlab_rails['db_password'] = 'removed'
postgresql['listen_address'] = '1.1.1.1'
postgresql['shared_buffers'] = "6GB"
postgresql['sql_user_password'] = 'removed'
postgresql['md5_auth_cidr_addresses'] = ['1.1.1.1/32']
gitlab_pages['dir'] = "/nfsdata/gitlab-pages"
geo_secondary_role['enable'] = true
geo_secondary['db_fdw'] = true

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:env:info)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production)

Results of GitLab application Check

  • Gitlab 11.8
  • Okta used for login
Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Edited by Fabian Zimmer