https://www.gooddata.com/ logo
Join Slack
Powered by
Hello folks. We’re experiencing an intermittent au...
# gooddata-cloud
e
Hello folks. We’re experiencing an intermittent authentication problem in the embedded GoodData instances we use for our dev environments. We have our instances setup to use our own Auth0 authentication. After navigating to the page that hosts our embedded GoodData instance, the auth redirect flow kicks in but then hits a problem on the GoodData domain, stays there, and displays this error:
Thankfully this is only occurring on our two dev environments, which have separate GoodData instances. We also have a staging and two production GoodData instances, and they are not (currently) affected by this problem.
For clarity I should highlight that we are using this custom sidepanel that includes folder grouping functionality: https://github.com/kazakovkirilliy/midaxo_dashboard_folding. The GoodData dev team built this for us, and we use it in place of the built in sidepanel. It requests the dashboards for the given workspace.
The issue can be reproduced every time when using Incognito mode in Chrome, but it does also occur in non-Incognito usage of Chrome.
Running our application locally, even in Incognito mode, does not reproduce the problem.
j
Hi Eoghan, this usually occurs when there is a misconfiguration in the authentication provider. However, is there a traceID in the dev tools that can help us search the logs?
Has anything changed recently with the provider? Or, was this ever working properly for you and when did it stop working?
e
Hi Joseph, thanks for the quick response. I don’t think anything has changed with our provider - we use Auth0 tenants for all our environments, and it’s only the dev ones that are having this problem.
We haven’t touched our own configs as far as I know, but it could be we overlooked something - I’ll double check.
This was working fine for us for both dev environments until about a month ago. I thought the root cause may have been that we needed a persistent logout against GoodData when logging out of our own product, but even after I added that we still hit the problem.
j
And are you able to find a traceID with the error?
e
I’ll try now
No traceID, from what I can see. Recorded the network activity and checked in the HAR file too.
j
Ok, no worries. I think I managed to find the log entry with the error. Please give me a moment to go through it
e
Nice, thank you
j
One more thing, did this just start happening today, or have you seen this behavior previously?
e
We’ve seen this intermittently for a month.
d
Can you confirm if it’s happening in this 2 devs: midaxo-eu-copy.cloud.gooddata.com and midaxo-eu-test.cloud.gooddata.com ?
e
I should have raised it earlier, but I honestly thought it could be due to not ensuring our GoodData session was logged out when logging out from our product. Plus, we recently had changes that meant our developers/testers were logging in with different profiles more frequently than previously - so again, I figured this was on our side.
b
Hello Eoghan, The error happens when GoodData is trying to handle the redirect parameter in a appLogin call 
appLogin?redirectTo=
do you add this parameter "manually"? Because usally it's generated by gooddata client and should point to a resource within GoodData. Of course the 500 error is not correct (should be 404).
e
Hi @Boris Yes we do populate the 
redirectTo
parameter as part of the src string set on the iframe to embed GoodData. But that’s been the case since February of last year, and it’s the case for our staging and two production instances where we’re not seeing this problem.
I wasn’t working on our initial integration of GoodData - I took over a few months after we went live. However I can see via our git history that we initially set the iframe source as 
${goodDataUrl}/dashboards/embedded/#/workspace/${workspaceId}/dashboard?showNavigation=true
Then there was change to add the 
appLogin?redirectTo=
:
Copy code
const dashboardsPath = `/dashboards/embedded/#/workspace/${workspaceId}?showNavigation=true`;

  // To ensure user gets properly logged in, the appLogin page need to be used.
  const loginUrl =
    `${goodDataUrl}/appLogin?redirectTo=` + encodeURIComponent(dashboardsPath);
The comment on the PR for this is “GoodData Iframe needs to use appLogin to ensure the user gets logged in. Embedded pages won´t redirect to auth0 without this.”
b
Hi Eoghan, That's seems correct, but in the errorous flow the redirect is set to your app (I assume): 
https%3A%2F%2Falpha.{your_app_domain}.xyz%2F%23%2Fanalytics
Is there any difference between the prod code and failing environment code?
e
Hello again @Boris There’s no difference between our production code and the failing environments. It’s strange alright that the redirect is set to our app. One piece I neglected to mention: we were having issues with the GoodData cookies not getting cleared, which meant that fresh logins were failing with unauthorized. So we added a fetch to the GoodData logout endpoint which seemed to help. It looks. like this:
Copy code
fetch(`${window.__config__.GooddataUrl}/logout`);
It’s only run initally when a user loads our Analytics page after login (we track that with a session storage variable). But perhaps this is part of the problem, given we see it most frequently in Incognito sessions. I’ll look into this further next week; I’m on leave from this afternoon and on Monday. Thanks for your help on this so far
b
Hi Eoghan, Sure thing. I think you might be on a right track with the logout - the redirect flow is rather complicated and the logout call does affect it. Definitely worth looking into.
r
Hi Eoghan,
Oops 🙂 Any luck with the above? It's been a while, just checking in!
2 Views
Open in Slack
PreviousNext
Powered by