Hello Team, Whenever gooddata API throws 401 , then it redirects to

<https://my-gooddata-hosted-url/appLogin?redirectTo=https%3A%2F%2Flocalhost%3A3001%2Freporting>

with error showing as JSON

{
  "title": "Not Found",
  "status": 404,
  "detail": "404 NOT_FOUND \"User is not registered\"",
  "traceId": "9959ed5ff1d5e8f8"
}

Now I want to handle a usecase wheneven

/appLogin?redirectTo=someurl

encounters 404 , It should capture and redirectTo url and append some query params to it and redirect back to URL without impacting it's original behavior, for this case it should be

someurl?query=queryValue

Hello. I am not sure about the SDK, but this should definitely be doable with components from react-router-dom. Unfortunately, I am not familiar enough with that to provide a quick solution.

@Jan Rehanek once it is redirected to

<https://my-gooddata-hosted-url/appLogin?redirectTo=https%3A%2F%2Flocalhost%3A3001%2Freporting>

we lost the control over it, so we can't do anything at this point of this , so expecting some solution from gooddata team

Hi @Jitender Singh, I’m not sure about the use-case of yours. When you call GD.CN

/appLogin?redirectTo=<some_url>

, the standard OAuth 2.0 authentication code flow with the OIDC provider is initiated. This means the user-agent goes through the series of redirections (HTTP 302) between the GD.CN (resource server) and the OIDC provider/issuer (authorization server) until the user is successfully logged in (obtains proper session cookies containing access/ID tokens). When the user is successfully “logged in”, they are directly redirected to the

<some_url>

provided by the

redirectTo

query parameter. If this

<some_url>

tries to use any GD.CN backend (REST) API, the mentioned session cookies are used to identify the user within the GD.CN. Here, if the user is not registered within the GD.CN metadata as well (see this article for more info), the 404 is returned with the “User is not registered” message. This all means that no 404s should go from the

/appLogin

endpoint, but from any other resource endpoint of the GD.CN you are trying to call originally via the frontend application. Therefore, there’s no such use-case with “encountering 404 on

/appLogin

endpoint”. If you are really encountering 404s as the direct response from the

/appLogin

endpoint, could you please provide us the network log (e.g. from the browser’s developer console)? Thanks.

Hi @Peter Plochan, attaching one screenshot showing the network calls. As you can see, in case of user not registered, flow remains: 1. 401 returned by any gooddata 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 6. Then again call to /appLogin?redirectTo=<some_url> which returns 404 error code After these network calls, flow never comes back to <some_url> where we can handle and show some error message in our application in case of user is not registered. And that gives very bad user experience. Hope this makes the flow and user case clear.

Hi @Narinder Kumar ah, now it’s clear, thank you. The point 6 (“Then again call to /appLogin?redirectTo=<some_url> which returns 404 error code”) should not be probably called. I need to confirm this with our frontend and backend developers, if it is an intention or it is a bug. Sadly, I don’t think there’s any workaround for this now without the fix directly in the GD.CN. I think the only possible way is to ensure that every user is registered in the Auth0 and GD.CN simultaneously, but as I understand you don’t want to do that. @Matyáš Kandl @Jan Soubusta any idea if there can be any other workaround for this?

Hi @Peter Plochan, Thanks for your response. Regarding simultaneous registration in Auth0 and GD.CN, its just that our use case is little complex with the existence of multiple tenants in Auth0. So it is kind of essential for us to handle this error in our application and show proper error message to the users. We will wait for further response on this on any possible workaround. Regards Narinder

Generally, it should be feasible to prepare a script based on our python sdk and "auto-provision" users from Auth0 to GoodData.CN. This could reduce the delay between when users are registered in Auth0 and when they are registered in GoodData.CN. How do you provision users into Auth0? Manually through a web UI, or programatically, e.g. from some configuration file containing users? Anyway, AFAIK, the second call to appLogin should not happen. As @Peter Plochan mentioned, we are going to investigate it on our side and hopefully we will be allowed to fix it easily.

Thanks @Jan Soubusta. We will wait for your further response based on the investigations by your team on this thread only.

Hi @Jan Soubusta, @Peter Plochan, Any updates from your end

Hello @Jitender Singh let me provide you answer about the update. We investigated described issue and prioritized necessary changes in app. We expect these changes/fixes will be delivered during (by end of) November 2022. Please let me know if this is acceptable. Regards

Thanks @Lubos Hilse for providing the update, can you confirm in which version of gd.cn the fix will be released ?

We expect to include a fix to version GoodData.CN 2.2

Hi @Lubos Hilse, we are planning an upgrade to GoodData.CN 2.0 version, can it be released in 2.0, this is very urgent for us

@Jitender Singh I understand, when do you plan do the upgrade?

@Lubos Hilse, I will check with my team and let you know

Hi all, discussed with Lubos, we will aim to add this to 2.1. From the upgrade perspective this should have no technical impact, neither version support vise.

Hi @Martin Svadlenka, Thanks for the update, can you help me with release date planned for 2.1 ?

2.1 has already been released: https://community.gooddata.com/product-updates/gooddata-cn-2-1-0-649

@Jitender Singh please let me remind, that regarding the issue we are talking about above, we aim to provide a hotfix to version 2.1.0 (2.1.x) where this will be included. In version 2.1.0 which is already released, the fix is not yet included

okay got it @Lubos Hilse, so what will be the planned date for 2.1.x which will have a hotfix

once we will know the exact planned date for hotfix 2.1.x I will provide you information here

Thanks @Lubos Hilse for the update !! cc @Balamurali Ananthan @Narinder Kumar @Kshirod Mohanty @Prashant Sharma @Alex Kearns