after upgrading to 6.0.0 the embedding dashboarding is broken

[sandy4597niko]

Bug description

4.1.4 embedding was working fine with guest token but after upgrading to 6.0.0 it is broken

In 4.1.4 the emedding dashboarding was working fine with superset. But recently we have upgraded our superset to 6.0.0 version it is giving below error.

{
"errors": [
{
"message": "403 Forbidden: You don't have the permission to access the requested resource. It is either read-protected or not readable by the server.",
"error_type": "GENERIC_BACKEND_ERROR",
"level": "error",
"extra": {
"issue_codes": [
{
"code": 1011,
"message": "Issue 1011 - Superset encountered an unexpected error."
}
]
}
}
]
}

getting above error after hitting the our domain instead of reports it is showing above error

Screenshots/recordings

In 4.1.4 the emedding dashboarding was working fine with superset. But recently we have upgraded our superset to 6.0.0 version it is giving below error.

{
"errors": [
{
"message": "403 Forbidden: You don't have the permission to access the requested resource. It is either read-protected or not readable by the server.",
"error_type": "GENERIC_BACKEND_ERROR",
"level": "error",
"extra": {
"issue_codes": [
{
"code": 1011,
"message": "Issue 1011 - Superset encountered an unexpected error."
}
]
}
}
]
}

getting above error after hitting the our domain instead of reports it is showing above error

Superset version

6.0.0

Python version

3.10

Node version

18 or greater

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

This is a frequently reported issue after upgrading to Superset 6.0.0. The 403 Forbidden error is most likely caused by missing guest role permissions that are now required in v6.0.0 but weren't in v4.x.

Most common fix: Add the can log on Superset permission to your guest role [1]. In v6.0.0, requests to /superset/log redirect to /login without this permission, causing the 403 error [2].

Here's a checklist of things to verify:

1. Guest role permissions — Your guest role now needs these permissions that weren't required before [3]:

   • can log on Superset (new and critical)
   • can read on CurrentUserRestApi (new — needed for the /api/v1/me/roles/ bootstrap call) [4]
   • can read on Dashboard, Chart, Dataset, Database
   • can explore and can explore_json on Superset

2. PyJWT compatibility — If you're also seeing HTTP 422 errors on the guest token endpoint, add this to your superset_config.py [5]:

   JWT_VERIFY_SUB = False

3. Session cookie settings — Ensure your config includes:

   SESSION_COOKIE_SAMESITE = "None"
   SESSION_COOKIE_SECURE = True

4. SDK version — Make sure you're using @superset-ui/embedded-sdk@0.3.0 or later for compatibility with Superset 6.0 [3].

Could you also check your Superset server logs for more detailed error messages? That would help pinpoint exactly which permission or endpoint is failing.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[sandy4597niko]

werkzeug.exceptions.Forbidden: 403 Forbidden: You don't have the permission to access the requested resource. It is either read-protected or not readable by the server.
got above logs from main container of superset after hitting the urls

[dosubot]

The werkzeug.exceptions.Forbidden: 403 Forbidden error confirms this is a server-side permission denial. Based on my earlier analysis, the most likely cause is the missing can log on Superset permission on your guest role — this is a new requirement in v6.0.0 that didn't exist in v4.x [1] [2].

To narrow it down further, could you check which specific URL path is triggering this error? The full stack trace in the logs should show it. Common culprits after upgrading are:

• /superset/log → Add can log on Superset to your guest role
• /api/v1/me/roles/ → Add can read on CurrentUserRestApi to your guest role [3]

If you can share the full stack trace (including the request path), that will confirm exactly which missing permission is causing the 403.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[sandy4597niko]

/superset/log → Add can log on Superset to your guest role this already there I am using Gamma role
/api/v1/me/roles/ can read on CurrentUserRestApi it is not there in permission instead of this can grant guest token on SecurityRestApi i have given but getting same issue

[dosubot]

A few things to address here:

The can read on CurrentUserRestApi permission does exist in v6.0.0, but several users have reported it being hard to find or invisible in the UI search, even though it exists in the database [1]. Try running superset init if you haven't already after upgrading — this synchronizes all permissions and makes them visible [2]:

superset db upgrade
superset init

After that, restart Superset and look again for CurrentUserRestApi in the permissions list.

Using Gamma as GUEST_ROLE_NAME is not recommended and has been reported to cause 403 errors even with seemingly correct permissions [3]. The best practice is to create a dedicated custom role (e.g., EmbedGuest) with only the minimum required permissions [4]:

GUEST_ROLE_NAME = "EmbedGuest"

Then assign this role exactly these permissions [5] [6]:

• can read on Dashboard, Chart, Dataset, Database
• can list, can get on Dataset and Database
• can explore, can explore_json on Superset
• can log on Superset
• can read on CurrentUserRestApi
• can time range on Api (if using time filters)

Also worth noting: Superset ignores the roles field in the guest token payload and always uses the server-side GUEST_ROLE_NAME setting instead [4], so the role must be configured in superset_config.py.

Could you try running superset init, creating a dedicated guest role with the permissions above, and see if that resolves the 403?

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[sandy4597niko]

why it was working earlier with 4.1.4 version with Gamma role

[dosubot]

Good question — the short answer is that Superset 6.0.0 introduced stricter permission enforcement for guest token users that didn't exist in 4.1.4. Here's what changed:

1. New can log on Superset permission requirement — In 4.x, the /superset/log endpoint didn't require this explicit permission for guest users. In 6.0.0, without it, requests to /superset/log redirect to /login, which causes the 403 [1].

2. can read on CurrentUserRestApi now enforced — The /api/v1/me/roles/ endpoint existed in 4.x but had looser permission checks. In 6.0.0, guest users need explicit can read permission on CurrentUserRestApi or the dashboard bootstrap fails with a 403 [2].

3. Flask-AppBuilder 5.0 upgrade — Superset 6.0.0 upgraded to FAB 5.0, which introduced stricter user attribute validation. FAB 5.0's security manager now checks for an active attribute during permission validation, which the GuestUser class didn't originally have [3]. This was patched, but overall FAB 5.0 tightened how permissions are evaluated.

4. Progressive security hardening in 5.0 — Even between 4.x and 5.0, Superset added query payload sanitization for guest users, stricter dashboard access verification, and payload modification detection [4] [5]. Version 6.0.0 continued this trend.

In essence, 4.1.4 had a more permissive security model where the Gamma role's broad permissions were "good enough" for guest token users. Version 6.0.0 requires explicit, fine-grained permissions for guest roles regardless of how broad the base role is. That's why I'd recommend creating a dedicated guest role with the exact permissions listed in my earlier comment rather than relying on Gamma.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.