Hi Team, We have a dashboard embedded in one of o...
# gooddata-cloud
a
Hi Team, We have a dashboard embedded in one of our applications, and external users are currently unable to access it even though they have access to the dashboard. We're seeing the following error:
Copy code
Tiger backend threw an error:
{
  "detail": "The requested endpoint does not exist or you do not have permission to access it.",
  "status": 404,
  "traceId": "dc1674e9d469ed3e8a91a940146c9e92"
}
Is there an ongoing issue that you're aware of that could be causing this?
k
Embedded Dashboard 404 Error Based on the knowledge sources, there is no confirmed ongoing platform issue at this time, but this type of error has several known causes. Here's what to check: Common Causes 1. Permission issues — Even if users appear to have dashboard access, they may be missing workspace-level permissions. Check that affected users have the necessary
Workspace.ANALYZE
permission for the workspace the dashboard is in. [Share Dashboards Troubleshooting] 2. Authentication/token issues — In embedded contexts, 401/404 errors are often caused by JWT token expiration or the auth provider not injecting the
Authorization: Bearer
header properly before the web components fire their API requests. [Auth issue case] 3. Transient platform issue — Past community cases show that 404 errors affecting embedded dashboards have sometimes been caused by temporary platform disruptions (e.g., infrastructure updates, datacenter issues) that resolved on their own. [Platform issue case] 4. OAuth or networking configuration — One case showed a 404 for all users caused by a newly deployed OAuth feature that was temporarily disabled to restore access. [OAuth issue case] Recommended Steps 1. Check the GoodData Status Page at support.gooddata.com for any active incidents in your region. 2. Verify permissions — Confirm external users have both dashboard and workspace-level access. 3. Check the
traceId
in the error response (if present) and share it with GoodData Support so they can look up the exact cause in backend logs. 4. Test outside the embed — Try accessing the dashboard directly on
cloud.gooddata.com
to determine if the issue is embed-specific or broader. 5. Capture a HAR file from the browser while reproducing the error — this is typically requested by GoodData Support to diagnose embedded authentication issues. If the issue is production-impacting, open a Severity 1 support ticket at support.gooddata.com with your organization URL, affected user details, and any
traceId
values from the error. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.
y
Hi Adham, Can you confirm if the dashboard was previously accessible to the users? If so, have they tried clearing their cache/cookies? Could you also share some details on how this is being embedded? Also a HAR file relating to this issue, to help us investigate further. Thanks.
a
They are surfacing issues and we don't have logs unfortunately . The traceId is included.
m
Hi Adham, Thank you for sharing the trace ID, it was very helpful. We have been able to do some initial investigation in our logs and have some leads we are following up on internally. We will share more details once we have a clearer picture. In the meantime, could you help us with the following: 1. Could you confirm which user(s) are experiencing the issue? (Name or email is fine.) 2. Is this affecting all embedded dashboards or only a specific one? 3. If possible, could you share a HAR file captured while reproducing the error? This will help us validate our findings and rule out any embed-specific factors.
j
Hi Adham, I agree with my colleague — a HAR file (captured as one of the affected external users) will be the key piece, since our logs show the dashboard data is actually being returned, so the blocker is likely on the client side. A few quick extras that would help: • The browser console error+ a screenshot of what the user sees. • Any recent changes on your side (app, SDK version, auth/JWT)? • Do the affected users share a specific role or user group(vs. the ones it works for)? Thanks!
a
Adding @Ryan Peters tot he conversation.
We did some investigating and identified a potential cross-tenant security bleeding issue. External users associated with one tenant are being directed to access resources belonging to a different tenant. As a result, they running into authorization failures due to insufficient access permissions. This is an example of the error we are seeing:
Copy code
Tiger backend threw an error: {
  "detail": "The requested endpoint does not exist or you do not have permission to access it.",
  "status": 404,
  "traceId": "11c8dd529647b8fd18e24f0026312760"
}
To answer your questions: Any recent changes on your side (app, SDK version, auth/JWT): • No, this issue has been ongoing, it just started happening in mass so we were alerted. Do the affected users share a specific role or user group(vs. the ones it works for • We tested this, and we see it happening across tenants where the users don't share both workspaces, so no. @Julius Kos @Mauricio Cabezas I sent the HAR File in a DM.
j
Hi Adham, This is Joseph from the GoodData Support Team. Both Julius and Mauricio are currently out of their business hours. Nevertheless, I can still assist from our side. I've checked the logs, but I cannot see that the user is hitting the other dashboards without permission. Would you be able to send the HAR file to me in DM as well?
m
Hi Adham and Ryan, we've created a support ticket on your behalf so we can investigate further and share findings more securely. Please keep an eye on your inbox, we'll continue the conversation there!
r
Hello! Can we actually schedule a 30 minute meeting to actually demonstrate this? We can reliably make it happen, and I think with a lot of the technical pieces, it's worth quickly popping into a meeting to discuss rather than a delay on finding underpinning issues.
d
Hello @Ryan Peters Yes, let's do a quick call. Let me send you an invite through the support ticket that Mauricio created.