Hello Team, We have recently did the migration of GoodData CN to version 2.3.2. In our setup, we utilize Auth0 silent authentication to authorize users from our domain. We've encountered an issue during the redirection process when using the following API endpoint: /login/oauth2/code/<gooddata-domain>. It appears that we are receiving a 302 status code, but the 'Location' field in the response header is displaying '/' where it should be the source domain url. Consequently, we're not being redirected back to our source application. We suspect there might be a configuration step we missed while setting up GoodData in the new version. Can you please help us investigate this?

Hi Prashant, could you please share with us the whole log from the dev console? Feel free to send it in DM along with the issuer URL. Also note that When configuring the external OIDC provider for your organization, you will have to make sure that the

oauthIssuerLocation

value ends with a trailing slash, like

<https://mycompany.eu.auth0.com/>

. Otherwise, the authentication will not work

Hi @Moises Morales, The Auth0 works for us, its just the redirection that's not working. Let me DM you the logs for the same.

FWIW, I think we are seeing a similar behavior on our end with the embedded web component flow. Where after all the 302's the user ends up in the gooddata application home

/

instead of the page that has the embedded web component.

Hi Prashant, I am looking into this (Moises provided me with the logs). In the OIDC flow, url parameters are passed between the apps and the browser, based on which the browser will do the redirects, so it seems something is missing in the configuration. But to pinpoint this further, let me ask you a few questions: Was this working before the upgrade? Which version of GD.CN you were running before? How do you consume GoodData? Through react components or embedded in an iframe in an app with some custom code?

Hi @Boris, I hope you're doing well. I wanted to provide some further information in the same order of your queries 1. Was this working before the upgrade? - Yes, it was working perfectly fine. - We recently migrated from GCP to AWS, and it seems that this migration may have caused the issue. - However, we did try to keep the same configuration during the migration. 2. Which version of GD.CN were you running before? - We were using GoodData 2.3.2. - In our previous environment (GCP), everything was working smoothly. - Specifically, the redirectURL in the /appLogin endpoint was successfully replaced in the Location parameter of the response headers for API /login/oauth2/code/<gooddata-domain>. 3. How do you consume GoodData? - We are consuming GoodData using React components. - Our authentication is implemented using the OIDC flow through GoodData analytical backend. We have thoroughly checked the configuration in AWS, ensuring that the authService.allowRedirect is correctly set and that the necessary authentication setup is in place. However, the issue persists. Considering the migration from GCP to AWS, we suspect that there might be some differences in the configuration or underlying infrastructure causing the issue.

I don't think this is about underlying infrastructure, if the client/browser wouldn't be able to make a redirect, I would assume that there will be some error message / or status code, but it's indeed strange considering the circumstances. To me it seems like app configuration issue - there are 3 applications in the equation - auth0, GoodData and the custom react app. I assume there were no changes done in auth0 in the process of migration, as I don't see any need. Not sure about the react app. In GoodData it would be either the helm chart itself (although I am not aware of any relevant config there), or in the organization itself (as mentioned here). The react app would be configured similar to what's mentioned here, right? It's still not clear to me from which version to which version you were migrating (as you only mention 2.3.2), I'll try to check if any relevant change happened between the versions (but I don't think there was).

Hi @Boris, minor update, we are using 2.5.1 gooddata CN version. Additionally, there are no change to the React app configuration.

We're currently using these GD.CN versions in our respective Cloud providers: GCP 2.3.2 (all environments) AWS 3.0.0 (dev) 2.5.1 (stage/prod)

Hello, I've did some testing and it seems that the oauth flow itself is correct ... the

/

as the last call location basically tells the client to redirect back to your original gooddata hostname without any URL parameters, which is expected. You obviously don't want to be redirected to the gooddata directly, but to your app with the GD elements. But such routing should be done on the level of the react app.

Hi @Boris , here are the flow occurring: 1. 401 returned by any gooddata call. (profile call) 2. /appLogin?redirectTo=<some_url> 3. call to GD.CN oauth2/authorization endpoint 4. authorize call to auth0 5. call to GD.CN login/oauth2/code/ endpoint(here response_header -> Location should have <some_url>.

@Boris According to the documentation below, the user should indeed be re-directed back to the original url. Is this not accurate? https://www.gooddata.com/docs/gooddata-ui/latest/learn/embed_dashboards/web_components/authentication/

Whenever a user is not authenticated with the GoodData server, the library will redirect the browser window to the SSO provider that you configured at GoodData. Once the user is logged in, the SSO provider will redirect the browser window back to the exact same page it was before the first redirect.

@Patrick Sexton that's a really good point, I will look deeper into that and let you know.

Thank you!

Hello, we most likely found the cause of the behaviour. We plan to have it fixed in the next version of GD.CN planned for realease on 30th of November.

Will that be a patch version of 2.5.* or a patch on 3.*?

Hi Patrick, I will be the next version, so 3.*

I think that may work for us. Though, I will share that is a little disappointing. This is a core feature set that GoodData offers, and it is disappointing that clients will be forced to do a major update to make it work.

Hi Patrick, I opened the discussion with our product team and they've agreed that it makes sense for it to be backported to previous versions. We are still figuring out the details, but most likely we will release CN v 2.5.2 where this issues should be fixed.

Thank you!

Hi Team, any updates on the fix. Which version shall we upgrade to fix the issue?

Hi Prashant, the issue will be fixed in the new released version (3.1). The release is planned for 14th of December (it was moved from 30 November). As for the backport to 2.5.*, it's not that straightforward, so we're trying to find the optimal approach. Sorry for the trouble.