Pawansingh3889 commented on issue #39834: URL: https://github.com/apache/superset/issues/39834#issuecomment-4816554550
I hit the same gap from the MCP side, so sharing what I found in case it helps move this toward a fix. The diagnosis above is right: with a JWT Bearer token the request authenticates (200), but g.user isn't resolved by the time FAB's authorization filters run, so can_access_all_databases() and the database/dataset base filters fall back to anonymous permissions and return count:0. The objects exist and the user has the perms; the filters just never see the user. What's worth flagging is that the MCP service already had to work around exactly this. superset/mcp_service/auth.py doesn't rely on the standard request flow to populate the user. It has its own resolver (get_user_from_request / _resolve_user_from_jwt_context) that pulls the identity from the validated token and sets g.user before any tool runs, specifically because the JWT context isn't otherwise available when authorization happens. The REST API path has no equivalent, which is why programmatic JWT clients (MCP-over-REST, provisioning scripts) get empty lists while a browser session works. The per-user workarounds in this thread (the FLASK_APP_MUTATOR before_request hook, and fetching the CSRF endpoint with the Bearer header to establish a session cookie) all do the same thing by hand: get g.user populated from the token before the filters execute. That works but it pushes a security-sensitive step onto every deployment. So the fix looks like resolving g.user from the validated JWT identity centrally in the request lifecycle, before the authorization filters run, so token auth and session auth converge on the same authenticated user. Essentially what the MCP service already does, but in the shared API path so every JWT client benefits. Before putting up a PR that touches the auth lifecycle, I'd want a steer on the approach you'd accept: handle it in the JWT auth integration (populate g.user right after token validation), or in the FAB before_request layer? Happy to implement with regression tests on the list endpoints once there's a direction. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
