Jira Cloud integration fails group linking when Split-brain DNS is used

Summary

When setting up the GitLab for Jira Cloud app with a self-managed GitLab instance that uses split DNS (same hostname resolving to different IPs on local network vs. public internet), the OAuth setup fails with a generic error message: Failed to load Jira Connect Application ID. Please try again.

For example, consider a scenario where:

  • Users will access gitlab.example.com via 192.168.1.1.
  • The GitLab instance is publicly accessible at the same DNS address of gitlab.example.com via: 203.0.113.26.

Workaround

This problem appears to be specific to when the end-users browser is located in the same local network as the GitLab server (or, they use the 'local' DNS). As a user, performing this setup via the 'Public Internet' (so, using the same 'public DNS' as what GitLab.com would use) seems to resolve this behaviour.

Note that once this setup is complete for selecting groups, the integration continues to sync just fine.

Steps to reproduce

  1. Deploy a Self-Managed instance. To match a customer ticket I've used 18.5.2, but this is still reproducible on the latest releases.
  2. Follow the initial setup including creating an OAuth application.
  3. Ensure that you configure the instance to use gitlab.com as the proxy, as expected for the Jira Cloud configuration.
  4. Within an Atlassian Jira environment, attempt to configure the app via the marketplace. Initial setup will proceed via the gitlab.com iframe.
  5. Once you've defined your Self-Managed instance, confirm that attempting to sign-in results in the Failed to load Jira Connect Application ID. Please try again. response. Browser tools will show a failed attempt to https://gitlab.example.com/-/jira_connect/oauth_application_id
    1. The browser console will also show:
Access to XMLHttpRequest at 'https://gitlab.example.com/-/jira_connect/oauth_application_id' from origin 'https://gitlab.com' has been blocked by CORS policy: Permission was denied for this request to access the `unknown` address space.

What is the current bug behavior?

This appears to be a result of how GitLab.com, acting as the proxy, makes a cross-origin request to the Self-Managed instance. This may have some similarity to this open issue, but I did not get the local network access errors.

What is the expected correct behavior?

We should be able to handle a situation where this split-brain DNS is used, but our docs should mention our continued preference on not using proxies/complicated systems with the integration.