We have configured CORS by using the following Ingress options:
nginx.ingress.kubernetes.io/cors-allow-headers: X-GDC-JS-SDK-COMP, X-GDC-JS-SDK-COMP-PROPS,
X-GDC-JS-PACKAGE, X-GDC-JS-PACKAGE-VERSION, x-requested-with, X-GDC-VALIDATE-RELATIONS,
DNT, X-CustomHeader, Keep-Alive, User-Agent, X-Requested-With, If-Modified-Since,
Cache-Control, Content-Type, Authorization
However, when doing GET or OPTIONS requests at https://example.com/api/profile the Access-Control-Allow-Origin header is always set to “*”.
Are we doing something wrong?
Best answer by Ulku KijasevView original
CORS headers were originally set up with the same value of
Access-Control-Allow-Originfor all organizations using nginx ingress annotations in Helm chart values (in
Since GoodData CN version 1.7.0, the configuration can be done the following way:
ingress.annotationsthat will be automatically applied for every existing and every newly created organization automatically.
allowedOriginsattribute of the respective organization as described in the linked doc article
The configuration you have made seems to be fine if you have multiple organizations and you want to have one UI application (running on another domain) same for all organizations.
In your application you see Access-Control-Allow-Origin header is always set to “*” for you requests? Are your requests to gooddata organization successful or do they fail with CORS errors?
I’ve successfully set up CORS, but now experiencing the following issue:
Sign in screen at https://localhost:8443/login does nothing. When trying to log in it sends a GET request to /api/profile and displays the “Unknown error” message under the password field.
Have you set up the organization as described in here. Did you prepare the organization.yaml and setup the administrator account in it? And after creating the organization then you can setup the authentication for configuring other users, which are composed of steps Creating bootstrap token, Setting up an OIDC identity provider and mapping users to organization as in doc. Please let us know if you have followed the steps for creating organization and administrator account.
I’ve set up the administrator account, created an organization, a bootstrap token, a workspace, mapped a user to the organization. I’m using built-in OIDC Dex provider.
Could you please give us more details about what happened. Did you manage to successfully log-in and it failed on communication during the
GET /api/profile. Or even the login wasn’t successful for some reason? Could you please send us a screenshot from the browser where the error occurred, as well as the failing API request and the response (at least the status code and not sensitive response headers). If you can provide us also logs it would be good.
Basically that is what I get when pressing the “Sign In” button:
In order to help workaround authentication errors, some colleagues used here workaround by starting the frontend app like this:
REACT_APP_DEV_TIGER_API_TOKEN=YWR… yarn start. Could you please try this and let us know if it solves your problem. Maybe it could help.
I tried different combinations of the variables in .env file:
Nothing helps at the moment.
We see that you’re getting error response 403 to GET request to /api/profile. This means you still have problem in authorisation part. You most probably have invalid CORS configuration, so your API requests are rejected because they don’t allow
localhostorigin. The fix could be adding
allowedHostsin the organization configuration, or you can add
nginx.ingress.kubernetes.io/cors-allow-originas explained above you can choose where to add depending on your needs. But it seems that
https://localhost:8443was not added as allowed origin in your CORS configuration.
What response code should it return in case of successful configuration? Because I assumed it returned 403 because a user was not logged in yet.
It should return you response 200 OK
It seems there’s unexpected interference between cors setup on ingress level and cors setup on organization level, so it really doesn’t work as expected. We will fix in in one of future releases, but till then there is the following workaround:
The “cors-allow-origin” annotation should contain comma-separated list of all domains where the CORS should be enabled for all organizations you have. Note, that you can’t control which domain should be enabled for which organization.
allowedOriginsto url for every Organization where you want CORS to be allowed. Following the example above, let’s say you want to set
allowedOrigins="https://localhost:8433"for Organization “devel.example.com” and
allowedOrigins="https://another.domain.com"for Organization “production.example.com”
This configuration is secure enough but has a small limitation - running pre-flight check (OPTIONS) from Origin localhost:8443 against production.example.com backend will return status 204, but the real call (GET. POST, ...) will fail with 403 as expected, because localhost:8443 is not allowed host on backend.
Hello, a brief update:
CORS setup works fine as far as you do NOT add any cors-related annotations to your ingress annotations (simply remove `nginx.ingress.kubernetes.io/enable-cors`, `nginx.ingress.kubernetes.io/cors-allow-headers` and `nginx.ingress.kubernetes.io/cors-allow-origin` from your customized values file and update your deployment. Removing these annotations is necessary to keep responses unmodified because now the CORS is completely managed by backend services.
Then, set `allowedOrigins` to list of allowed origin URLs; don’t forget to include schema and also port if it differs from default value for given schema (80 for http and 443 for https).
These two settings should be sufficient to make the CORS working.
Please us know if it helped.