Ilya0527 commented on issue #40225:
URL: https://github.com/apache/superset/issues/40225#issuecomment-4482589823
The phrasing "g.user was not set by JWT middleware" is misleading — it
doesn't mean the middleware ran and failed, it means it never executed for this
request. In 6.1.0 the MCP routes are served by a sub-app (FastMCP/ASGI mount),
and Flask's `@before_request` JWT handler only fires for routes in Flask's own
URL map. `/mcp/*` requests bypass it, so by the time the tool dispatcher
reaches `flask.g` there's no `user` populated — or no Flask request context at
all. The MCP_AUTH_ENABLED + JWT-keys-configured branch passes because both are
static config reads; the failure is structural, not a Keycloak token problem.
Your token's `aud`/`iss`/signature are never inspected.
Two cheap checks before chasing Keycloak specifics (audience claim, JWKS
rotation, RS256 vs HS256):
1. Add `log.info("jwt mw path=%s", request.path)` at the top of the JWT
`before_request`. If `/mcp/*` calls don't appear, the middleware isn't being
invoked.
2. Set `MCP_DEV_USERNAME=admin` and retry `health_check`. If it succeeds,
the resolver chain works end-to-end; only the JWT→g.user bridge for MCP is
missing.
If both confirm, the fix is registering auth on the MCP dispatcher itself
(or an ASGI auth middleware on the FastMCP app), not Keycloak realm tuning.
--
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]
