Access Denied toasts displaying Randomly for Custom "readonly" role

[paulsonkevgit]

Bug description

We've created a custom role in Superset called "readonly" with assigned permissions to allow view-only access. But the users assigned this role frequently encounter "Access Denied" toaster notifications while navigating through the Superset UI — even when performing actions that should be permitted.

Allowed Permissions (for readonly Role):

[can list on SavedQuery, can read on SavedQuery, can read on CssTemplate, can read on ReportSchedule, can read on Chart, can read on Annotation, can read on Dataset, can recent activity on Log, can read on Log, can drill on Dashboard, can read on Dashboard, can read on Database, can read on Query, can show on MyUserOAuthModelView, can userinfo on MyUserOAuthModelView, can list on MyUserOAuthModelView, can show on RoleModelView, can list on RoleModelView, can show on RegisterUserModelView, can list on RegisterUserModelView, can get on OpenApi, can show on SwaggerView, can get on MenuApi, can this form get on DashboardModelView1, can this form post on DashboardModelView1, can list on AsyncEventsRestApi, can read on AdvancedDataType, can read on AvailableDomains, can write on DashboardFilterStateRestApi, can read on DashboardFilterStateRestApi, can read on DashboardPermalinkRestApi, can read on Explore, can read on ExploreFormDataRestApi, can read on ExplorePermalinkRestApi, menu access on Row Level Security, can read on Row Level Security, can read on Tag, can time range on Api, can dashboard on Superset, can explore json on Superset, menu access on Tags, can read on SecurityRestApi, can read on RowLevelSecurity, menu access on Security, menu access on List Users, menu access on List Roles, menu access on User Registrations, menu access on Action Log, menu access on Home, menu access on Data, menu access on Databases, menu access on Dashboards, menu access on Charts, menu access on Datasets, menu access on Manage, menu access on Plugins, menu access on CSS Templates, menu access on Alerts & Report, menu access on Annotation Layers].

Screenshots/recordings

Superset version

4.1.3

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[bot]]

This is a common challenge with custom readonly roles in Superset. The "Access Denied" toasts usually happen because some UI actions (like "+ CHART" or "VIEW ALL") trigger backend API calls that require permissions not included in a minimal readonly role—sometimes even for actions that seem read-only. For example, viewing dashboards and charts reliably requires permissions like can dashboard on Superset, can dashboard permalink on Superset, can explore json on Superset, can read on Chart, can read on Dashboard, and can read on DashboardPermalinkRestApi, plus datasource access on for each dataset you want users to see. Missing any of these can cause random "Access Denied" toasts, even if most things work as expected [discussion].

Some UI elements (like "+ CHART") may try to POST or access endpoints that require write permissions, which your readonly role intentionally lacks—so clicking them will always show an error. This is expected unless you hide or disable those buttons for readonly users [code reference].

To refine your role, check the Superset backend logs when a toast appears; the logs will usually specify which permission was missing for the denied action [discussion]. After updating permissions, restart Superset to ensure changes take effect, as caching can cause stale permission states [issue].

There’s no official minimal readonly role, but community-tested lists suggest starting with the permissions above and iteratively adding any others reported in the logs as missing. Avoid granting write or edit permissions to keep the role truly readonly [discussion].

If you want to avoid these toasts entirely, consider hiding or disabling UI elements that trigger actions your role cannot perform. This usually requires custom frontend tweaks, as Superset does not currently hide all such buttons for readonly users by default.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[paulsonkevgit]

@dosu, @rusackas

Is there a way to create a readonly role such that the user isnt able to edit or delete or add dashboards ,databases , charts etc.??
What are the permissions that i should grant to make sure the access denied toasts don't appear in the superset/welcome page??

[dosubot[bot]]

Yes, you can create a readonly role in Superset that prevents users from editing, deleting, or adding dashboards, databases, charts, etc. To avoid "Access Denied" toasts on the welcome page, make sure your role has at least these permissions: can_read (and/or can_list/can_show) on Dashboard, Chart, SavedQuery, Dataset, Database, and Log resources. Also include can dashboard on Superset, can explore json on Superset, and datasource access on for each dataset the user should see. These cover all the API calls the welcome page makes for listing and viewing objects [source].

Do not grant any write, edit, or delete permissions (like can write, can delete, can add, or set_embedded) on these resources. This will block all modification actions [source].

However, UI elements like "+ CHART" or "+ DASHBOARD" buttons will still appear and trigger access denied toasts if clicked, because they try to POST to endpoints your role can't access. Superset does not hide these buttons for readonly users by default—you'd need custom frontend tweaks to fully suppress those toasts [source].

If you want to be sure you've covered all cases, check Superset's backend logs when a toast appears—the logs will show which permission was missing for that action [source].

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[rusackas]

I'd follow @dosu's advice here as a starting point, but it looks like you got most of the ones it mentions other than datasource access on. I don't personally manage permissions much (we offer/build a hosted service that more or less covers these bases) so I'm not sure. Are there certain actions you're taking when these pop up? Any logs on the server side or browser console messages of interest, to show what's being blocked?

[paulsonkevgit]

@dosu @rusackas

I have actually implemented RLS feature and edited the dashboard properties for giving access to the specific dashboards for the readonly user can see. The following is the Action log that i see while encountering the "access is denied" message.

[paulsonkevgit]

@dosu
I have actually implemented RLS feature and edited the dashboard properties for giving access to the specific dashboards for the readonly user can see. The following is the Action log that i see while[+] encountering[/+][-] seeing[/-] the[+] "access[/+][-] access[/-] is[+] denied"[/+][-] denied[/-] message.

CAN U RESPOND

[dosubot[bot]]

The "Access Denied" toasts for your readonly role are almost always caused by missing critical read permissions or by UI elements (like "+ CHART" or "VIEW ALL") that trigger backend API calls requiring write permissions, which your role intentionally lacks. Even with RLS and dashboard property edits, you must ensure the role has all necessary read/list/show permissions for dashboards, charts, datasets, saved queries, and logs. Missing any of these (especially can_read or datasource access on for datasets) will cause denied toasts, even for actions that seem read-only [source].

The welcome page and dashboard list require: can_read (and/or can_list/can_show) on Dashboard, Chart, SavedQuery, Dataset, Database, and Log, plus can dashboard on Superset, can explore json on Superset, and datasource access on for each dataset the user should see [source]. Do not grant any write, edit, or delete permissions.

UI elements like "+ CHART" will always show "Access Denied" if clicked by a readonly user, because they POST to endpoints your role can't access. Superset does not hide these buttons by default—you'd need custom frontend tweaks to fully suppress those toasts [source].

To refine your role, check the backend logs when a toast appears—the logs will specify which permission was missing for the denied action. Iteratively add only the missing read permissions, and restart Superset to clear any permission cache [source]. RLS only filters data within datasets; it doesn't override missing object-level permissions.

If you want to avoid these toasts entirely, the only way is to hide or disable UI elements that trigger actions your role cannot perform. This requires frontend customization.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[paulsonkevgit]

@dosu @rusackas

I have added the permissions suggested by @dosu AND removed some permissions from readonly role (like menu access for roles, data security , manage etc because in settings drop down of readonly user i dont want to see those option )

UPDATED readonly permissions now

[can list on SavedQuery, can read on SavedQuery, can read on CssTemplate, can read on ReportSchedule, can read on Chart, can read on Annotation, can read on Dataset, can recent activity on Log, can read on Log, can drill on Dashboard, can read on Dashboard, can read on Database, can read on Query, can show on MyUserOAuthModelView, can userinfo on MyUserOAuthModelView, can list on MyUserOAuthModelView, can show on RoleModelView, can list on RoleModelView, can show on RegisterUserModelView, can list on RegisterUserModelView, can get on OpenApi, can show on SwaggerView, can get on MenuApi, can this form get on DashboardModelView1, can this form post on DashboardModelView1, can list on AsyncEventsRestApi, can read on AdvancedDataType, can read on AvailableDomains, can write on DashboardFilterStateRestApi, can read on DashboardFilterStateRestApi, can read on DashboardPermalinkRestApi, can read on Explore, can read on ExploreFormDataRestApi, can read on ExplorePermalinkRestApi, can read on Row Level Security, can read on Tag, can time range on Api, can dashboard on Superset, can explore json on Superset, menu access on Tags, can read on SecurityRestApi, can read on RowLevelSecurity, menu access on Home, menu access on Dashboards, menu access on Charts, menu access on Datasets, menu access on Plugins] --

---

The following are the permissions of the GAMMA user, gamma user WHO is not encountering the access denied toaster.

Gamma -- [can show on SavedQuery, can add on SavedQuery, can delete on SavedQuery, can edit on SavedQuery, can list on SavedQuery, can tag on Chart, can export on Chart, can write on Chart, can read on Chart, can read on Dataset, can recent activity on Log, can tag on Dashboard, can drill on Dashboard, can view chart as table on Dashboard, can view query on Dashboard, can delete embedded on Dashboard, can export on Dashboard, can get embedded on Dashboard, can cache dashboard screenshot on Dashboard, can write on Dashboard, can read on Dashboard, can read on Database, can this form get on ResetMyPasswordView, can this form post on ResetMyPasswordView, userinfoedit on MyUserOAuthModelView, can show on MyUserOAuthModelView, can userinfo on MyUserOAuthModelView, can add on MyUserOAuthModelView, can delete on MyUserOAuthModelView, can edit on MyUserOAuthModelView, can list on MyUserOAuthModelView, can get on OpenApi, can show on SwaggerView, can get on MenuApi, can this form get on DashboardModelView1, can this form post on DashboardModelView1, can list on AsyncEventsRestApi, can read on AdvancedDataType, can read on AvailableDomains, can invalidate on CacheRestApi, can write on DashboardFilterStateRestApi, can read on DashboardFilterStateRestApi, can write on DashboardPermalinkRestApi, can read on DashboardPermalinkRestApi, can get on Datasource, can external metadata by name on Datasource, can external metadata on Datasource, can read on EmbeddedDashboard, can read on Explore, can write on ExploreFormDataRestApi, can read on ExploreFormDataRestApi, can write on ExplorePermalinkRestApi, can read on ExplorePermalinkRestApi, can write on Tag, can bulk create on Tag, can read on Tag, can estimate query cost on SQLLab, can format sql on SQLLab, can show on DynamicPlugin, can list on DynamicPlugin, can query form data on Api, can query on Api, can time range on Api, can get value on KV, can store on KV, can share chart on Superset, can share dashboard on Superset, can csv on Superset, can dashboard on Superset, can dashboard permalink on Superset, can explore json on Superset, can slice on Superset, can log on Superset, can explore on Superset, can fetch datasource metadata on Superset, menu access on Tags, can list on Tags, can tags on TagView, can read on SecurityRestApi, can read on RowLevelSecurity, menu access on User Details, menu access on Home, menu access on Data, menu access on Databases, menu access on Dashboards, menu access on Charts, menu access on Datasets, menu access on Plugins] ------------------------------------------------------------------------------------------------------------------------------------------

Is Gamma users much more privilaged than the readonly user. Even with the updated permissions for read only user i encounter the Access is denied message for reaonly user at 4 places mainly

1)At welcome page

2)After removing the menu access also the listing user names ,listing roles page(Even if menu access of that is hided - i can still go to the URL of roles and list user - Can i some way block those permissions for the readonly user also to visit those sites?)

3)When a specific dashboard is selected...

4)After user has logged out (and reaches the login page)

[dosubot[bot]]

Yes, Gamma users are much more privileged—they have write, edit, delete, export, and advanced permissions, which is why they don’t see “Access Denied” toasts. Your readonly role is correctly restricted, but a few things are causing the errors:

1. Welcome page: If you still see “Access Denied” toasts, double-check that your readonly role has can_read, can_list, and can_show on Dashboard, Chart, SavedQuery, Dataset, Database, and Log, plus can dashboard on Superset, can explore json on Superset, and crucially, datasource access on for every dataset the user should see. Missing any of these will cause denied toasts, even for read-only actions. Also, UI buttons like "+ CHART" will always show a toast if clicked, since they require write permissions—these can’t be hidden by permissions alone and need frontend tweaks to fully remove [source].

2. User/role listing pages: Removing menu access only hides navigation links. To block direct URL access, you must remove can list and can show permissions on RoleModelView and UserModelView (MyUserOAuthModelView) for the readonly role. Superset enforces backend access using @has_access and @permission_name("read") on these views, so without those permissions, users get a denied error even if they enter the URL directly [source].

3. Dashboard widgets: “Access Denied” errors here usually mean the user is missing datasource access on for the underlying datasets, or lacks can read on Chart/Dashboard. RLS only filters data—it doesn’t override missing object-level permissions [source].

4. Logout/login page: These errors are session-related, not role-specific. Superset now redirects unauthenticated users to the login screen if they try to access a restricted dashboard, and after login, sends them back to the dashboard. If a logged-in user lacks access, they’re redirected to the dashboard list with an error message [source].

Frontend tweaks: Superset is starting to hide some UI elements (like “View in SQL Lab”) if the user lacks the right permission, but not all buttons are permission-aware yet. Full suppression of denied actions requires explicit frontend customization [source].

Checklist for readonly roles:

• Grant all necessary read/list/show permissions and datasource access on for datasets.
• Remove all write/edit/delete permissions.
• Remove can list/can show on sensitive models to block direct URL access.
• Use backend logs to identify missing permissions when denied toasts appear.
• Consider frontend tweaks to hide or disable buttons that trigger denied actions.

Let me know if you want details on how to identify missing dataset access or need help with frontend tweaks.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[paulsonkevgit]

@dosu

SO is there a way i could remove the Access denied by adding some permissions or REMOVING some other ??
If yes could you please lis out the permissions that i have ro remove

[can list on SavedQuery, can read on SavedQuery, can read on CssTemplate, can read on ReportSchedule, can read on Chart, can read on Annotation, can read on Dataset, can recent activity on Log, can read on Log, can drill on Dashboard, can read on Dashboard, can read on Database, can read on Query, can show on MyUserOAuthModelView, can userinfo on MyUserOAuthModelView, can list on MyUserOAuthModelView, can show on RoleModelView, can list on RoleModelView, can show on RegisterUserModelView, can list on RegisterUserModelView, can get on OpenApi, can show on SwaggerView, can get on MenuApi, can this form get on DashboardModelView1, can this form post on DashboardModelView1, can list on AsyncEventsRestApi, can read on AdvancedDataType, can read on AvailableDomains, can write on DashboardFilterStateRestApi, can read on DashboardFilterStateRestApi, can read on DashboardPermalinkRestApi, can read on Explore, can read on ExploreFormDataRestApi, can read on ExplorePermalinkRestApi, can read on Row Level Security, can read on Tag, can time range on Api, can dashboard on Superset, can explore json on Superset, menu access on Tags, can read on SecurityRestApi, can read on RowLevelSecurity, menu access on Home, menu access on Dashboards, menu access on Charts, menu access on Datasets, menu access on Plugins]

THis is the Action log that was seen when Access denied toaster came up

these are the current permissions

[dosubot[bot]]

To minimize "Access Denied" toasts for your readonly role, you should:

• Remove any write, add, edit, or delete permissions. In your current list, specifically remove can write on DashboardFilterStateRestApi—this is a write permission and not needed for readonly access. Double-check for any other permissions that start with can write, can add, can edit, or can delete and remove those as well.
• To block readonly users from accessing user/role listing pages (even via direct URL), remove can list and can show on RoleModelView and MyUserOAuthModelView (and any similar user/role views) from the readonly role. This will prevent backend access, not just hide the menu [source].
• Keep only the necessary read/list/show permissions for Dashboard, Chart, SavedQuery, Dataset, Database, and Log, plus can dashboard on Superset, can explore json on Superset, and datasource access on for each dataset the user should see [source].

Even with these changes, UI elements like "+ CHART" will still show "Access Denied" if clicked, because they require write permissions. Superset does not hide these buttons for readonly users by default—removing them requires custom frontend tweaks [source].

If you still see denied toasts after these changes, check the backend logs for the exact missing permission and adjust as needed. RLS only filters data; it does not override missing object-level permissions.

Summary:

• Remove: can write on DashboardFilterStateRestApi, all can write, can add, can edit, can delete permissions, and can list/can show on user/role views.
• Keep: all necessary read/list/show permissions and datasource access on for datasets.
• UI toasts from "+ CHART" and similar actions can only be fully suppressed with frontend customization.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[paulsonkevgit]

@dosu

Can i somehow diable all "Access is Denied mesages" from superset_config.py

[dosubot[bot]]

No, there isn’t a configuration option in superset_config.py to disable or suppress all “Access is Denied” messages globally. These messages are triggered by backend permission checks and surfaced in the frontend UI, which isn’t controlled by a config flag or setting in superset_config.py. The only way to fully suppress these toasts is through custom frontend code changes—Superset intentionally shows these errors for security and user feedback, and this behavior is consistent across the codebase reference.

If you want to explore frontend tweaks to hide or disable error toasts, let me know and I can point you to relevant code or approaches.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[david-heward-unmind]

We are running into this issue now.
We don't see them when running embed in a test domain, but do in another.
@dosubot do you think that could be to do with some settings that we've created around talisman_config. Both domains use the same guest user and dashboard ids. So nothing much else is changing.

[dosubot[bot]]

Yes, this can absolutely be caused by differences in your talisman_config, especially the Content Security Policy (CSP) settings. For embedded dashboards to work in multiple domains, your TALISMAN_CONFIG in superset_config.py needs to include a frame-ancestors directive that lists all allowed domains for embedding. If one domain is missing from this list, Superset will block embedding there and you'll see "Access is Denied" toasts—even if the guest user and dashboard IDs are the same. After updating TALISMAN_CONFIG, you must restart Superset for changes to take effect.

Also, check if you have a GUEST_TOKEN_VALIDATOR_HOOK or any custom logic that could be rejecting guest tokens based on domain or other criteria, as this can also cause domain-specific access issues even with identical users and dashboards.

To troubleshoot: compare the TALISMAN_CONFIG (especially frame-ancestors and other CSP directives) between your environments, and check for any guest token validation hooks. Look for CSP or access denied errors in the browser console and Superset logs when embedding fails. More details on this setup are in the official docs and codebase.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}