Configure CORS headers
This page is only relevant for you for self-hosted repository hub: GitHub Server, GitLab Server or Bitbucket Server, and to let users open Hackolade data models from that repository hub using the Hackolade browser application: https://studio.hackolade.com. You may skip it if it is not the case.
Problem
By default, a web browser (e.g. Chrome, Edge) does not allow a script loaded from an origin to send HTTP requests to another origin. That security mechanism is known as the same-origin policy.
The same-origin policy of the browser will prevent the Hackolade Studio browser application (which is loaded from https://studio.hackolade.com) from querying your self-hosted repository hub (which is hosted at a different origin, if self-hosted.) As a consequence, the application will throw an error when a user tries to connect to your repository hub:
The connection failed because <your self-hosted repository hub> rejected the cross-origin request from https://studio.hackolade.com.
Solution
To let the Hackolade Studio browser application contact your self-hosted repository hub, you need to enable cross-origin resource sharing (CORS). This comes down to configuring the following HTTP headers for your repository hub.
The location where you need to configure those headers depends on your infrastructure.
- If you use GitHub Server, then this document suggests that CORS should be enabled by default. So no action is required.
- If you use GitLab Server, then this discussion suggests that CORS should also be enabled by default for /api requests. So no action is required either.
- If you use Bitbucket Server, then CORS is not enabled by default and there is unfortunately no configuration properties for it. The solution is to set up a reverse proxy (e.g. nginx, traefik) in front of your Bitbucket Server instance and to configure the HTTP headers for CORS there.