After user logged out, getting Internal Server Error in browser

[nagarajmmu]

Bug description

Hi All

We are using superset 4.1.1
We are facing issue, when user logout, user will get Internal Server Error in browser.

Until user clear the browser Cookie and Cache user not able to re-login, once browser Cookie and Cache cleared, user able to re-login.
Same issue happens when user not using superset for a long time in browser.

Steps to reproduce.:

1. Config superset as below:
   a. Integrate auth login with Azure AD
   b. Provide AUTH_ROLE_PUBLIC = 'NoAccess' (NoAccess role does not have any permissions)
   c. Deploy superset in Kubernetes with helm.
2. user login to superset, very thing works fine.
3. Once user logged out, user will get Internal Server Error in browser.
4. User should clear browser Cookie and Cache to re-login again.

Please let us know, how we can resolve this issue.
As of now we didn't observe error in the logs when user logged out.

Please let us know, how we can resolve this issue.

Error screenhot:

Thanks
Nagaraj M M

Screenshots/recordings

Error screenshot:

Superset version

master / latest-dev

Python version

3.9

Node version

16

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]

Based on the information available, this issue appears related to session management and the way Superset handles authentication/logout, especially with Azure AD and the AUTH_ROLE_PUBLIC = 'NoAccess' setting. While there are no directly matching issues or official documentation addressing this exact error, here are some actionable insights and areas to investigate:

1. Session Management: Superset uses Flask and Flask-Login for session management, and can use Flask-Session for server-side sessions if SESSION_SERVER_SIDE is enabled. Session cookies are encrypted with the SECRET_KEY and are essential for identifying user sessions on the server side. If session cookies become invalid or corrupted, it can cause authentication issues that persist until cookies are cleared [source].

2. Role Configuration: Setting AUTH_ROLE_PUBLIC = 'NoAccess' means users who are not authenticated have no permissions. If, after logout, the session is not fully cleared or the browser still holds an invalid session cookie, Superset may attempt to treat the user as "public" but with no access, potentially triggering an error state.

3. Frontend Behavior: The frontend checks session validity and will redirect to login if the session is expired or invalid. However, if the backend returns an unexpected error (like a 500 Internal Server Error) instead of a 401 Unauthorized, the frontend may not handle it gracefully, resulting in the error you see [source].

4. No Error in Logs: If you do not see errors in the Superset logs, try increasing the log level to DEBUG for both Superset and your web server (e.g., Gunicorn, Nginx) to capture more detail about what happens during logout.

Suggestions to try:

• Temporarily set AUTH_ROLE_PUBLIC to a role with minimal permissions (not NoAccess) and see if the error persists. This can help determine if the issue is related to the lack of permissions for public users.
• Ensure your SECRET_KEY is unique and not the default, as session issues can arise from an insecure or default key [source].
• Double-check your Azure AD and OAuth configuration for any session or token expiry settings that might interact poorly with Superset's session handling.
• If using server-side sessions, verify that your session backend (e.g., Redis, filesystem) is healthy and accessible.
• Review your Kubernetes and Helm deployment for any customizations to session or cookie handling.

If none of these steps resolve the issue, consider enabling more detailed logging and capturing the exact HTTP response and stack trace when the error occurs. This information will be crucial for further troubleshooting or for reporting a bug upstream.

To reply, just mention my name @dosu.

---

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

[rusackas]

Do you believe this is a core Superset bug, or is there a custom security manager involved that might be the issue? I'm tempted to move this to a Help/Q&A discussion, but you can probably find many other threads here and on Superset Slack about AD integration.

[hainenber]

Any accompanying logs would be super helpful, imo. If it's indeed Internal Server Error, maybe some insights can be revealed.