You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When a user is banned in Grottocenter while they have an active Superset session (established via #1694's JIT auth flow), their Superset session remains valid for up to 1 hour. During this window, the banned user can still access BI dashboards and data.
This is a known limitation of the stateless JWT + session-based approach: once Superset establishes a Flask session, it has no mechanism to check back with the GC API for revocation events.
Describe the solution you'd like
Active session revocation propagation from Grottocenter to Superset. When a user is banned in GC (via BlacklistService.revoke()), their Superset session should be invalidated promptly.
Possible approaches (to be evaluated during design):
Webhook from GC API to Superset — on ban, GC API calls a Superset endpoint that invalidates the user's session. Requires a new internal endpoint on Superset + service-to-service auth.
Periodic session validation — Superset's security manager calls the GC API on every request (or every N minutes) to check if the user is still in good standing. Adds latency and coupling.
Shorter session TTL — reduce from 1 hour to 10-15 minutes. Doesn't eliminate the window but shrinks it significantly. Simplest to implement.
Redis pub/sub — if/when Redis is added to the Superset infrastructure, use a pub/sub channel for revocation events. Only viable after Redis is deployed.
Describe alternatives you've considered
Accepting the 1-hour window as-is. For a volunteer community BI tool with low abuse risk, this may be permanently acceptable. The follow-up is here to track the decision explicitly.
Is your feature request related to a problem? Please describe.
When a user is banned in Grottocenter while they have an active Superset session (established via #1694's JIT auth flow), their Superset session remains valid for up to 1 hour. During this window, the banned user can still access BI dashboards and data.
This is a known limitation of the stateless JWT + session-based approach: once Superset establishes a Flask session, it has no mechanism to check back with the GC API for revocation events.
Describe the solution you'd like
Active session revocation propagation from Grottocenter to Superset. When a user is banned in GC (via
BlacklistService.revoke()), their Superset session should be invalidated promptly.Possible approaches (to be evaluated during design):
Webhook from GC API to Superset — on ban, GC API calls a Superset endpoint that invalidates the user's session. Requires a new internal endpoint on Superset + service-to-service auth.
Periodic session validation — Superset's security manager calls the GC API on every request (or every N minutes) to check if the user is still in good standing. Adds latency and coupling.
Shorter session TTL — reduce from 1 hour to 10-15 minutes. Doesn't eliminate the window but shrinks it significantly. Simplest to implement.
Redis pub/sub — if/when Redis is added to the Superset infrastructure, use a pub/sub channel for revocation events. Only viable after Redis is deployed.
Describe alternatives you've considered
Accepting the 1-hour window as-is. For a volunteer community BI tool with low abuse risk, this may be permanently acceptable. The follow-up is here to track the decision explicitly.
Additional context
BlacklistService.revoke()sets a per-userrevoked_beforetimestamp; tokens withiat < revoked_beforeare rejected