2 Commits

Include renames

Author	SHA1	Message	Date
mathiasandClaude Opus 5	e1e9a2e30e	feat(auth): every accepted request names the path that granted it ... Closes #60. Closes #58 (fixed in mcp-chassis v0.7.0, consumed here). Three auth paths reach this server and none of them said so on success. PassthroughMiddleware logged nothing at all, success or failure. While verifying #59 end to end there was no way to confirm from the logs whether calls were using the new PAT pass-through — the caller's own Gitea PAT, the caller's own identity — or falling through to the shared JWT/static path. The only available reasoning was inference from which failures were absent. INFO mcp auth accepted auth_path=passthrough caller=alice token_fp=... INFO mcp auth accepted auth_path=jwt caller=mathiasbq token_fp=... INFO mcp auth accepted auth_path=static token_fp=... The first line matters more than the other two. Pass-through is the path where a request acts as a SPECIFIC Gitea user; an audit trail that cannot say which identity performed a write is not an audit trail. chassisauth.Fingerprint, not a local equivalent. The chassis emits token_fp on its own accepted and rejected lines, and two different fingerprints for the same token cannot be correlated — which is the only reason the field exists. Exported from the chassis in v0.7.1 for exactly this. A token that is not a valid PAT still falls through SILENTLY. The chassis owns the verdict, and logging here as well would double-count every static-token request, since all of them reach this middleware first. Asserted, because "logs nothing on the failure path" is indistinguishable from "was never called". Also lands #58 by consuming mcp-chassis v0.7.0: a JWT presented to a server with no JWT auth configured now reports jwt_auth_not_configured rather than static_token_mismatch. That log line is what sent a debugging session into re-running the OAuth flow while the credentials were valid the whole time. Verified: task check EXIT=0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-14 20:59:04 +02:00
mathiasandClaude Sonnet 5	5601927dc8	feat(auth): per-caller Gitea PAT pass-through (#59) ... Replaces the shared GITEA_MCP_DEFAULT_TOKEN for all callers. When a request's bearer validates directly against Gitea's own /api/v1/user, that token is used for every upstream call this request makes instead of the service PAT, and the caller identity comes from Gitea's own login rather than the proxy header. Any other bearer (static token, JWT, none) falls through unchanged to the existing chassis auth. Prep: Authentik now SSOs into Gitea (infra a32801c), so each real user can mint their own PAT from their own linked account. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-22 08:22:50 +02:00