Skip to content

Cannot sign into the GitLab for Jira Cloud app when using a reverse proxy in front of GitLab

This issue specifically targets the installing the GitLab for Jira app manually installation method.

See #434085 (closed) for issues with reverse proxies when using the connect the GitLab for Jira Cloud app installation method.

Problem

When following the installing the GitLab for Jira app manually and you have a reverse proxy in front of your self managed GitLab instance using different FQDNs, the Jira app hangs when you attempt to sign in. This is because it attempts to complete the sign in on the GitLab instance FQDN and not the reverse proxy FQDN.

This is a common topology with some of our users:

  • GitLab instance, external_url = https://gitlab.internal (only available in an internal network and inaccessible from the internet)
  • Reverse proxy, FQDN https://gitlab.mycompany.com (accessible from internet, proxies traffic to gitlab.internal)

Based on my quick testing, I noticed the following once one of the workarounds is implemented:

  • GitLab will still be able to send updates successfully back to Atlassian/Jira via the various Sidekiq workers (like JiraConnect::SyncBuildsWorker and JiraConnect::SyncBranchWorker).
  • The development panel in Jira will reference the internal FQDN for commits and branches. If the client has access to both the internal and reverse proxy FQDNs, then the development panel will work as expected. For clients that don't have access to the reverse proxy FDQN, then the development panel won't link off correctly - this is likely the same problem as #391432 (closed)

Proposal

Allow users that configure a reverse proxy in front of GitLab to use an alternative FQDN for the GitLab for Jira Cloud app so the development panel works as expected when the client is on an external network.

Workaround

  • When setting up the GitLab for Jira Cloud app, complete the steps on a client that has access to both the reverse proxy and internal GitLab FQDNs.
  • Use the same FQDN for the GitLab instance external_url on the reverse proxy as well.

Investigation

Update: These investigation steps are deprecated and should not be followed.

I had a play around with this and I was able to get the app partially working using different FQDNs.

Disclaimer: I have not fully tested this and not all functionality in the development panel works, and this method is not supported. I've opted to make this information available to help our product team determine where code changes are needed.

In these steps, gitlab.mycompany.com is the reverse proxy FQDN.

  1. Optional (only if you want the Jira app to show your reverse proxy FQDN in the app listing page): Update Atlassian::JiraConnect#gitlab_host to return your reverse proxy FQDN:

    # Create a backup
cp /opt/gitlab/embedded/service/gitlab-rails/lib/atlassian/jira_connect.rb /opt/gitlab/embedded/service/gitlab-rails/lib/atlassian/jira_connect.rb.bak

# Update the host to your reverse proxy FQDN
sed -i -e 's/Gitlab.config.gitlab.host/"gitlab.mycompany.com"/g' /opt/gitlab/embedded/service/gitlab-rails/lib/atlassian/jira_connect.rb

    To revert the change, reverse the replace in the sed command or move the backup file generated to the original location and restart GitLab.

    Restart GitLab so the changes are applied

    sudo gitlab-ctl restart

  2. Ensure that the OAuth application created for Jira Cloud contains your reverse proxy FQDN in the redirect URI eg. https://gitlab.mycompany.com/-/jira_connect/oauth_callbacks

  3. In Jira, install the app in development mode. The manifest file should upload correctly. Don't click Get Started just yet.

  4. This change works around the problem when signing into the Jira app. On your GitLab instance, open a Rails console sudo gitlab-rails c and run the following. Replace <ATLASSIAN_SUBDOMAIN> with your one and gitlab.mycompany.com with your reverse proxy FQDN:

    installation = JiraConnectInstallation.where(base_url: "https://<ATLASSIAN_SUBDOMAIN>.atlassian.net")
installation.update(instance_url: "https://gitlab.mycompany.com")

  5. In Jira, you can now click the Get Started button and proceed to sign into GitLab, and link your groups.

References

Refer to #434085 (closed) for example reverse proxy configuration.

Edited by Anton Smith