Skip to content

Jira development panel links off to the wrong FQDN when using a reverse proxy in front of GitLab

This issue specifically targets the connect the GitLab for Jira Cloud app installation method.

See #434262 (closed) for issues with reverse proxies when using the installing the GitLab for Jira app manually installation method.

Problem

The GitLab for Jira Cloud app doesn't work as expected when a self managed GitLab is behind a reverse proxy, and both GitLab and the reverse proxy are using different FQDNs when following the connect the GitLab for Jira Cloud app installation method. This method does use gitlab.com as the Jira Connect Proxy.

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)

If the reverse proxy is configured correctly, users should be able to connect the GitLab for Jira Cloud app successfully using the reverse proxy FQDN and link groups successfully.

These are our observations on how the GitLab for Jira Cloud app works via a reverse proxy:

  • 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 GitLab instance FQDN/external_url and not the reverse proxy FQDN. This means that if you click on any actions within the development panel that redirect back to GitLab, they won't work

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 in Jira works as intended.

Workaround

Use the same FQDN for the GitLab instance external_url on the reverse proxy as well.

References

Test reverse proxy configs:

# Nginx
server {
  listen *:80;
  server_name gitlab.mycompany.com;
  server_tokens off;
  location /.well-known/acme-challenge/ {
    root /var/www/;
  }
  location / {
    return 301 https://gitlab.mycompany.com:443$request_uri;
  }
}
server {
  listen *:443 ssl;
  server_tokens off;
  server_name gitlab.mycompany.com;
  ssl_certificate /etc/letsencrypt/live/gitlab.mycompany.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/gitlab.mycompany.com/privkey.pem;
  ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
  ssl_protocols  TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers off;
  ssl_session_cache  shared:SSL:10m;
  ssl_session_tickets off;
  ssl_session_timeout  1d;
  access_log "/var/log/nginx/proxy_access.log";
  error_log "/var/log/nginx/proxy_error.log";
  location / {
    proxy_pass https://gitlab.internal;
    proxy_hide_header upgrade;
    proxy_set_header Host             gitlab.mycompany.com:443;
    proxy_set_header X-Real-IP        $remote_addr;
    proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
    #access_log off;
  }
}
# HAProxy
frontend https_front
  bind *:80
  bind *:443 ssl crt /etc/haproxy/certs/certificate.pem alpn h2,http/1.1
  mode http
  redirect scheme https if !{ ssl_fc }
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
  acl tls req.ssl_hello_type 1
  acl host_gitlab hdr(host) -i gitlab.mycompany.com

  use_backend gitlab if host_gitlab


backend gitlab
  server gitlabserver x.x.x.x:80 check
Edited by Anton Smith