403 Forbidden on embedded dashboard in production (worked fine in test), missing can read on CurrentUserRestApi permission?

[geovanasullivan]

Hi everyone,

I've embedded a Superset dashboard into our internal site using the guest token flow, and everything worked correctly in our test environment. However, when deploying to production, the dashboard fails to load entirely and returns a 403 Forbidden error (the guest token is generated successfully, but the dashboard itself does not render).

Environment:

Superset version: 6.0.0
FEATURE_FLAGS = {"EMBEDDED_SUPERSET": True} — configured
Guest role: Public (default GUEST_ROLE_NAME)
Service account used to request guest tokens has roles: Gamma + a custom role with can_grant_guest_token
Logged in as Admin while troubleshooting

What I've already checked/tried:

Confirmed the dashboard's "Embed dashboard" settings include the production domain in Allowed Domains
Confirmed resources: [{ type: "dashboard", id: DASHBOARD_UUID }] is correctly passed when generating the guest token
Added datasource access permissions on all underlying datasets to both Public and Gamma roles
Confirmed the dashboard's "Roles" field (Edit properties) includes both Public and Gamma
Searched for the permission can read on CurrentUserRestApi, which other threads mention as critical for embedded dashboards — this permission does not appear anywhere in the Public/Gamma/Admin permission lists, even though I can see plenty of other API-related permissions

My question:
Is can read on CurrentUserRestApi expected to exist by default in 6.0.0, or could it have a different name in this version? If it genuinely doesn't exist in 6.0.0, could that be causing this 403, or should I be looking elsewhere?

Any guidance would be greatly appreciated. Thanks!

[dosubot[bot]]

Hi @geovanasullivan! I'm Dosu and I'm helping the Apache Superset team.

This is a well-documented issue with embedded dashboards in Superset 6.0+. The 403 is almost certainly coming from the /api/v1/me/roles/ endpoint, which the embedded frontend calls during initialization before rendering the dashboard [1]. The guest user's role needs can read on CurrentUserRestApi to pass that call.

Why you can't find the permission: The CurrentUserRestApi class (which serves /api/v1/me/) is defined in superset/views/users/api.py, and its permissions are auto-created by Flask-AppBuilder. However, in some 6.0.x builds the permission doesn't appear in the role editor UI even though it exists in the database. Multiple users have reported this exact behavior — it was confirmed working in 6.0.0 but broke in 6.0.1RC1 and later [2].

What to do:

1. If you're using a custom guest role (via GUEST_ROLE_NAME): search for can read on CurrentUserRestApi in the permission list when editing the role. If it doesn't show up in the dropdown, try searching by permission ID 267 in the database directly [2].

2. If GUEST_ROLE_NAME is defaulting to Public: the same applies — the Public role needs this permission. The recommended practice is actually to create a dedicated guest role rather than using Public [3]:

   GUEST_ROLE_NAME = "EmbedGuest"

3. Quick sanity check: confirm the 403 is specifically on /api/v1/me/roles/ by checking the browser Network tab. That narrows it to this exact permission gap.

4. Other permissions commonly missed for embedded dashboards [3]:

   • can log on Superset (required for /superset/log)
   • can time range on Api (required for time filters)
   • can read on Dashboard, can read on Chart, can read on Dataset

One user who hit this same 403 in 6.0.1 confirmed that adding can read CurrentUserRestApi to their custom role resolved it immediately [2]. If the permission is genuinely invisible in your UI, you may need to add it via the database or API directly.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[geovanasullivan]

Thanks for the earlier guidance, that was really helpful in confirming the root cause. @dosu

Update: I confirmed that can read on CurrentUserRestApi did not exist in the database for this 6.0.0 install at all (not just hidden in the role editor UI). I created the missing permission_view manually via the Security REST API (POST /api/v1/security/permissions-resources/ with permission_id for can_read and view_menu_id for CurrentUserRestApi), then assigned it to the Public role through the normal UI.

However, the 403 error persists, and I've now isolated it to a different stage of the flow:

In our local/test environment, the guest token is generated successfully and the embedded dashboard loads without issues.
In production, the backend call to generate the guest token isn't succeeding at all, it's failing before a token is even returned, using the exact same SUPERSET_URL, SUPERSET_USER, and SUPERSET_PASSWORD values as local.

Since both environments point to the same Superset instance and use identical credentials, this looks like it may be network-related (e.g., the production server's outbound IP not being allowed to reach the Superset instance, or some proxy/firewall layer in front of it), rather than a permissions issue this time.

Has anyone run into guest token generation failing specifically from a production server while working fine locally against the same Superset instance? Any pointers on what to check on the network/infrastructure side would be appreciated.

[dosubot[bot]]

Glad the earlier fix helped! Since both environments point to the same Superset instance, the most likely culprit is how the production server's backend-to-Superset HTTP calls handle sessions and CSRF, not a Superset-side permission issue.

Here's what to check, in order of likelihood:

1. CSRF token not being passed correctly

The POST /api/v1/security/guest_token/ endpoint is not in the CSRF exempt list [1], so it requires a valid CSRF token. Your production backend needs to:

• First call GET /api/v1/security/csrf_token/ to obtain a token
• Include it as an X-CSRFToken header on the guest_token POST
• Crucially, reuse the same HTTP session (cookies) across the login → csrf_token → guest_token calls. If your production HTTP client isn't maintaining a session/cookie jar across requests, the CSRF token won't match the server-side session and you'll get a 403.

2. SESSION_COOKIE_SAMESITE blocking cookies on cross-origin POSTs

The default is SESSION_COOKIE_SAMESITE = "Lax" [2], which means session cookies are not sent on cross-origin POST requests. If your production backend is on a different origin than Superset, the session cookie won't be included, authentication fails, and you get a 403. Locally this works because the calls are same-origin (localhost → localhost).

If cross-origin is unavoidable:

SESSION_COOKIE_SAMESITE = "None"
SESSION_COOKIE_SECURE = True  # Required when SameSite=None

3. CORS not enabled

CORS is disabled by default (ENABLE_CORS = False) [3]. If your production backend makes browser-side or cross-origin requests to Superset, you may need:

ENABLE_CORS = True
CORS_OPTIONS = {
    "origins": ["https://your-production-domain.com"],
    "supports_credentials": True
}

That said, if your backend server (not the browser) is making the guest token call, CORS shouldn't apply — CORS is a browser enforcement mechanism. This matters more if you're fetching the token client-side.

4. Network/proxy layer

Since you mentioned identical credentials and the same Superset instance, also check:

• Whether a reverse proxy or load balancer in front of Superset strips or modifies headers (e.g., Cookie, X-CSRFToken, Referer)
• Whether ENABLE_PROXY_FIX = True is set — needed if Superset is behind a proxy so Flask reconstructs the correct scheme from X-Forwarded-* headers [4]
• Whether the production server can reach Superset's internal address at all (a quick curl to the login endpoint from the production server would confirm connectivity)

Quickest diagnostic step: Run the exact sequence of calls from the production server using curl with -v (verbose) to see the full request/response headers. Look specifically at whether the session cookie is being returned on login, whether it's being sent back on the CSRF and guest_token calls, and what the 403 response body says.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[geovanasullivan]

@dosu

Update: I ran a manual test that narrowed this down significantly.

I executed the exact same login call (POST /api/v1/security/login) manually via curl from an external machine (not our production server), and it succeeded — returned a valid access_token and refresh_token. This confirms:

The app-wooall credentials are correct
The account is not locked/disabled
There's no simple firewall/IP block preventing external access to the Superset instance in general

However, our .NET backend (ASP.NET Core, using HttpClient inside an async Controller method) still fails with a raw 403 Forbidden response — no JSON body, just the plain text "Forbidden". This is different from a typical Superset-generated auth error, which usually returns a JSON error message.

I noticed the Superset instance is behind Cloudflare (Server: cloudflare in response headers). My working theory is that HttpClient in .NET does not send a User-Agent header by default, and Cloudflare's bot protection may be blocking requests that lack one — which would explain why curl (which always sends a User-Agent) succeeds while the .NET backend doesn't.

My questions:

Does Superset (or a Cloudflare layer in front of it) have any default WAF/bot-protection rules that specifically block requests missing a User-Agent header, or with generic/empty ones?
Is there a way to check Cloudflare-level firewall/WAF logs (separate from Superset's own action_log) to see if these specific requests are being blocked before they even reach Superset's application layer?
Besides User-Agent, are there other headers commonly required by Cloudflare/WAF rules that a plain server-to-server HTTP client might be missing compared to a browser or curl?

For context: the same credentials, same Superset instance, same endpoint — only difference is the origin/client making the call (external curl vs. our .NET production backend). Any guidance on where to check next (Cloudflare dashboard, Superset logs, or something else) would be appreciated.

[dosubot[bot]]

Your theory is very likely correct. The plain text "Forbidden" with no JSON body is the key clue — Superset itself never returns a plain text "Forbidden" response. Superset's API error handlers always return structured JSON payloads for 403 errors [1]. A plain text "Forbidden" is characteristic of an upstream layer (in your case, Cloudflare) blocking the request before it ever reaches Superset.

To answer your questions:

1. Does Superset block requests missing User-Agent?

No. Superset has no middleware that checks or enforces User-Agent headers. The middleware stack (Flask-Talisman, Flask-Compress, etc.) handles security headers and CSP but never inspects User-Agent for filtering [2]. This is entirely a Cloudflare behavior — Cloudflare's default bot protection rules do block or challenge requests with missing/empty User-Agent headers, and this is one of the most common triggers for server-to-server calls being rejected.

2. How to check Cloudflare logs?

In the Cloudflare dashboard for your domain:

• Go to Security → Events (formerly Firewall Events) to see blocked/challenged requests with details on which rule triggered and from what IP
• Filter by your production server's outbound IP to find the specific blocks
• The event will show the rule ID and description (likely something like "Missing User-Agent" or a managed bot rule)

3. Other headers Cloudflare commonly expects?

Beyond User-Agent, Cloudflare's managed rules and bot detection can also flag requests that:

• Lack an Accept header
• Have an unusual or missing Accept-Encoding
• Come from IP ranges flagged as datacenter/hosting IPs (your production server's IP may be in a datacenter range that gets higher scrutiny)
• Don't send a Connection header

Recommended fix for your .NET backend:

httpClient.DefaultRequestHeaders.Add("User-Agent", "YourApp/1.0");
httpClient.DefaultRequestHeaders.Add("Accept", "application/json");

If adding User-Agent alone doesn't resolve it, the Cloudflare Security Events log will tell you exactly which rule is blocking the requests — that's the definitive next step. You may also need to whitelist your production server's IP in Cloudflare's WAF rules if it's on a datacenter IP range that triggers bot detection even with proper headers.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.