Our users are getting issues when doing 'explore f...
# gooddata-cloud
f
Our users are getting issues when doing 'explore from here' or trying to edit visualizations created by them. It blocks them but after 4-5 attempts it goes through eventually. What could be causing this? I've observed this myself on my PC using customers login (without extensions & 3rd party cookies accepted).
j
Hi Filip, based on the screenshot alone it is a bit difficult to tell, but it appears to be an authentication/access issue. Is there a TraceID from the console you could pull that would allow us to check our logs?
Also, how exactly are you embedding here?
f
embedding is via iframe. It doesn't give a trace id for some reason, just a 401
ah wait, here's something
3f58cb42ecfc250094ccd455e238a799
- it's one of 19 trace ids in a massive error
🙌 1
j
let me have a look and see if I can dig up anything
m
Hi Filip, to assist our investigation can you please replicate the issue once again generate a HAR file at the same time and provide us with this related HAR file so we can review this?
f
@Michael Ullock sent har file in DM
j
Hi Filip, I've checked the HAR file and found the following error:
Copy code
"The method cannot be called before initializeClient method.\"),this.apiToken=e,this.clients.forEach((e=>this.initializeClient(e)))}}class c extends l{jwt;tokenIsAboutToExpireHandler;secondsBeforeTokenExpirationToCallReminder;expirationReminderId=-1;constructor(e,t,i,n=60){super(e,t),this.jwt=e,this.tokenIsAboutToExpireHandler=i,this.secondsBeforeTokenExpirationToCallReminder=n,this.startReminder(e)}initializeClient(e){super.initializeClient(e)}updateJwt=(e,t=60)=>{((e,t)=>{const i=s(t);if(s(e).sub!==i.sub)throw new Error(\"The new JWT does not belong to the same subject as the previous one.\")})
It looks like there is expiration in tokens. I've found an article dealing with this type of issue: https://stackoverflow.com/questions/65410275/confusion-using-jwt-when-calling-api
f
I'll have a look thanks @Joseph Heun. Could this also be responsible for clients losing share access to their own dashboards that they created? We've had such issues a couple of times during the last 2 months.
We haven't changed anything over the last 10 months (BE, FE & API wise - all changes were within GD itself, like new dashboards, new data model etc), but we have been getting issues for 2 months now, and mainly they are 401s and 404s - usually one followed by the other. What I don't get is why it loads the dashboard, but then can't do explore from here (it works on 4th to 5th try eventually) or create new dashboards, giving a 401 error. I will send another HAR file from another client.
This seems to be coming from your end, due to cloudfront
Copy code
VM125 gd.2f1c1ff37c583db5d74e.js:2 Uncaught (in promise) h: No session or session expired
    at <https://d3ij350uzls03h.cloudfront.net/analyze/gd.2f1c1ff37c583db5d74e.js:2:6006248>
    at r (<https://d3ij350uzls03h.cloudfront.net/analyze/gd.2f1c1ff37c583db5d74e.js:2:6006378>)
    at u.loadProfile (<https://d3ij350uzls03h.cloudfront.net/analyze/gd.2f1c1ff37c583db5d74e.js:2:5782501>)
    at async u.obtainCurrentPrincipal (<https://d3ij350uzls03h.cloudfront.net/analyze/gd.2f1c1ff37c583db5d74e.js:2:5782325>)
    at async u.authenticate (<https://d3ij350uzls03h.cloudfront.net/analyze/gd.2f1c1ff37c583db5d74e.js:2:5784213>)
    at async authApiCall (<https://d3ij350uzls03h.cloudfront.net/analyze/gd.2f1c1ff37c583db5d74e.js:2:6004539>)
    at async <https://d3ij350uzls03h.cloudfront.net/analyze/gd.2f1c1ff37c583db5d74e.js:2:7568542>
m
Hi Filip, I just wanted to let you know or team are looking into this issue and will get back to you with more details as soon as possible. Thanks for your patience in the meantime
r
Hi Filip, Radek from the GD Technical support team here - the issue has been passed to me to look over. I'll have to do some more checking, but at a first look, both the previous error and the Cloudfront-related ones are session expiration errors. Let me see if I can find more specific info and get back to you! 🙂
f
but this is an issue on your side no?
Copy code
this is GD issue. token is generated GD-side, we are just passing it by, using "on behalf" method. so we are logging user in GD, getting the token and passing token to all the subsequent GD calls. We can't affect what is happening inside GD iframe, but this issue happened exactly in GD UI located in GD iframe. This happens irregularly but our code and data are the same for the user affected
^^ from our engineers
👀 1
r
Can you elaborate on the way you're authenticating the users please? This sounds like you're somewhere halfway between OIDC and JWT, but not quite either of the two approaches, I'd like to understand the approach a little better.
f
we started with OIDC before GD even had JWT support. It started in our trial, and we use it via aws cognito. As far as I know we only use it for admin login on https://zentist.cloud.gooddata.com/. It only has 15 users (all admins) in cognito. Everything else (embedded iframes) uses JWT. That's as technical I can get, if you need more details I would have to ask the dev who worked with both OIDC & JWT in our systems.
Not sure if this helps, dev told me this:
Copy code
When user logs in we create JWT access token and JWT refresh token. 
Access token is valid 60 minutes. Refresh token is valid 240 minutes.
FYI this happens ONLY if all cookies (obviously including GD's) was deleted. if cookies (GD cookies in particular) exists, all works fine. Are there any updates here? More and more clients are noticing this issue...
r
Hi Filip, thank you for the info! If all cookies get deleted, it makes sense that this would break - as you mention, this would include GoodData session cookies, and we rely on these to keep everything working. Does the scenario where people delete cookies while trying to use the app happen often?
f
But why is it not getting correct cookies within the GD JS itself? It gets them correctly upon login and we pass the token on, it then crashes... We have clients that login once every 24 hours, once every week or even once every month...
r
Ok so, the way I understand this: 1. The user logs in to your app 2. You generate a JWT access & refresh token 3. Everything works fine 4. The same user logs in to your app a while later 5. You generate a new JWT access & refresh token 6. The iframe works, but "Explore from here" and Visualization edits fail Does that match? If that's the case, what causes the users to start working again? Is it just the amount of re-tries or anything else?
f
1. user logs in - we generate jwt & refresh token. a. all dashboards and vizs are displaying correctly b. it doesn't matter how long user was logged out for, this step always works. 2. user tries to explore from here or create a new private dashboard and it crashes 3. when user relogs in, new tokens are created yes. I don't think it has anything to do with relogging. It just so happens that when user refreshes the page 5 or 6 times, everything starts working perfectly. If it was an issue on our end, issue would reproduce every time, not sometimes. Have a look at these pictures, some of your JS within the iframe doesn't even send the token...
Can I please have an update, it's been 3 weeks since I reported this? If you can't find the root cause of this, might I suggest we get together in a call with our API engineers and do a deep dive? This is really impacting our business...
r
Hi Filip, I was about to suggest the same, I've been trying to figure this out for a while, hence the silence here - I can do pretty much any time between 10am-5pm CET tomorrow, or first half of Friday (10am-2pm CET). If you're ok scheduling something, you can send an invite to radek.novacek@gooddata.com, alternatively I can do it, just let me know who I should invite and what time works for you 🙂
f
@Radek Novacek booked a meeting for tomorrow at 4pm CET.
🙏 1
@Radek Novacek I had to reschedule for tomorrow at 1pm CET time, because our engineer is not available today
r
Thank you for letting me know, I'll be there 👍
f
Following our call, I am now waiting for permission to share our test details.
@Radek Novacek @Michael Ullock any updates on this?