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
- Log into the
primary
node and open a session in your browser. - Open another browser tab and type in the address to the
secondary
- The browser tab which was used to access the
secondary
is automatically redirected to theprimary
. This can be observed by inspecting the URL. As a regular user it is not possible to access thesecondary
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)