Bug description
The enhancement previously merged in #30380 was broken in two places, as far as I can tell:
1. A PR last week now just throws a 404 if a user doesn't have access to a dashboard. If not logged in, a login should be attempted first, passing the target URL as a next parameter.
2. The massive theming PR #31590 moved Login CRUD functionality into Superset, instead of relying on FAB. That may be what caused the next URL parameter to be lost during the roundtrip to the SSO provider.
The prior behavior should be restored: if an anonymous user tries to view a dashboard (whether or not it exists), they should be prompted to log in. Upon completing login, then the dashboard access check is performed and they are granted or denied as normal.
Superset version
master / latest-dev, I branched off it this morning
Browser
Firefox
Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [x] 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.
Screenshot
This is from 6.0.0rc2:
I've moused-over the Login button when taking this screenshot. You can see that the Login button link appears in the bottom-left of the screenshot. Note that it's missing the /?next=https:// ... that was present in the URL, and thus that redirect path will be lost in the process of logging in.
Comment From: dosubot[bot]
You're correct that the redirect flow for not-logged-in users trying to view a dashboard has regressed. The intended behavior—redirecting anonymous users to the login page with a next parameter, then checking access after login—was implemented in PR #30380, which updated the dashboard view logic to handle this flow.
However, PR #35237 refactored error handling for dashboard access denial, switching to safer URL construction and removing flash messaging. This change may have inadvertently caused the 404 response or broken the login redirect with the next parameter, especially in SSO scenarios.
The current dashboard access logic in superset/views/core.py still attempts to redirect anonymous users to the login page with the next parameter when access is denied, but the login view in superset/views/auth.py does not explicitly handle or propagate the next parameter after authentication. This gap likely causes the loss of the intended redirect after SSO or theming changes, as the new login flow (migrated from FAB in PR #31590) doesn't replicate the nuanced handling of next for SSO/OAuth/SAML flows (source).
There are related issues and discussions about this pattern and its regressions, but no open tickets specifically track this exact bug in the latest master. The code and recent PRs confirm the regression and the likely cause: missing or incomplete handling of the next parameter in the new login/auth flow, especially after SSO roundtrips (source).
If you need to restore the prior behavior, focus on ensuring the login view and any SSO/OAuth handlers correctly propagate the next parameter after authentication, so users are redirected to their original dashboard destination post-login.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other 
