Hi, I am using <GoodData.CN> with Auth0 as our OID...
# gooddata-ui
e
Hi, I am using GoodData.CN with Auth0 as our OIDC provider. I am using
@gooddata/sdk-ui@9.0.1
Our GD is hosted on a subdomain
<https://prod.analytics.company.com>
Our application is on
<https://www.company.com>
which is a React application with an embedded react GD dashboard component on the
/dashboard
route. We use
TigerBackend
with
ContextDeferredAuthProvider
Since upgrading from
2.4.0
to
2.5.0
of
<http://GoodData.CN|GoodData.CN>
it seems like our silent login no longer works. When the user first hits
/dashboard
they are redirected to
<https://prod.analytics.company.com>
and immediately sees the list of workspaces. (We do not want them to use the dashboard outside of the embedded react app) The second time the user hits
/dashboard
this is no longer the case. No redirection happens and the embedded dashboard loads. This is probably because there is now a cookie set for
<https://prod.analytics.company.com>
. I can confirm that removing this cookie reverts to the first behaviour. Doing a little troubleshooting, I can see that internally,
createTigerAuthenticationUrl
is redirecting me to
<https://prod.analytics.company.com/appLogin?redirectTo=https://www.company.com/dashboard>
However this never happens the first time around. Has anything changed in GD.CN since 2.4.0? I have tried updating the reactsdk to
9.2
but it doesn't work entirely due to a different error. Can anybody please assist?
e
no solution - just wanted to say hi to the fellow Eugene
馃憢 1
actually after reading your post more closely we did experience a similar issue where the frontend couldn't auth into the API and setup this redirect flow.
Copy code
const backend = tigerFactory()
    .onHostname(GD_BASE_URL)
    // redirect authentication flow
    .withAuthentication(new ContextDeferredAuthProvider(redirectToTigerAuthentication));
e
That's exactly how we have our backend setup but it doesn't prevent our users from being redirected to GD on first login
j
Hi @Eugene Lee have there been any changes in your app or gooddata integration or auth0? Or upgrade from
2.4.0
to
2.5.0
was the only change when it started to behave like you are describing?
e
Hi Jan, it seems to correspond with our upgrade to 2.5.0
j
Hi Eugene, we鈥檝e released a new version
3.0
would you be able to test if the described behaviour persists?
a
Hello @Eugene Lee @Jan Kos We have practically the same setup and have also been experiencing this behaviour for a while now. Even after upgrading to 3.0 the issue persists. Have you found a solution/workaround or detected the problem鈥檚 origin?
馃啓 2
e
No I wasn鈥檛 able to solve this. I was hoping upgrading to 3.0 would solve the issue but I haven鈥檛 gotten around to updating.
a
Sadly, that is not the case from our end. Despite this not implying any information leak, this generates a very broken flow and confusion for our end-users.
b
Hello, thank you for trying... I understand the situation is not ideal and very possibly it could be some bug on our side given that it was working before. We are going to look into it.
Just to note here, we identified the issue and we plan to fix it in the next GD.CN release, scheduled to 30th of November.
馃檶 1
e
Hi Boris, just wondering if there is an ETA on the next release for GD.CN. The fix for this issue is very crucial for us. Thanks!
b
Hi Eugene, the release is now planned for 14th of December, sorry for the delay...