While verifying #59 (v0.12.0/v0.12.1) end to end, I could not confirm from server logs which auth path a given /mcp request actually took. chassisauth.BearerMiddleware only logs on rejection (mcp auth rejected reason=... status=401); PassthroughMiddleware logs nothing at all, success or failure.
Concretely: after re-authing the claude.ai connector, I wanted to confirm whether the resulting calls were using the new PAT pass-through (caller's own Gitea PAT, own identity) or falling through to the existing JWT/shared-token path. The only way to reason about it was inference (a JWT would fail ValidateToken against Gitea and fall through) — there was no direct signal in the logs either way.
Proposed fix
Add one structured log line per successful /mcp auth, distinguishing the path taken, e.g.:
INFO mcp auth accepted path=passthrough caller=alice token_fp=...
INFO mcp auth accepted path=jwt caller=mathiasbq token_fp=...
INFO mcp auth accepted path=static token_fp=...
token_fp should be a fingerprint/hash, never the raw token (matches the existing rejection log's token_fp convention).
Acceptance criteria
A test asserting PassthroughMiddleware logs path=passthrough with the resolved caller on a successful PAT validation.
A test (or manual verification) confirming the existing JWT/static success paths in mcp-chassis's BearerMiddleware emit an equivalent path=jwt/path=static accepted line — may require a small mcp-chassis change if that library doesn't expose a success hook today.
Refs
gitea-mcp#59 (PAT pass-through), v0.12.0/v0.12.1
gitea-mcp#57/#58 (related: existing rejection-path logging had its own correctness bugs)
## Problem
While verifying #59 (v0.12.0/v0.12.1) end to end, I could not confirm from server logs which auth path a given `/mcp` request actually took. `chassisauth.BearerMiddleware` only logs on *rejection* (`mcp auth rejected reason=... status=401`); `PassthroughMiddleware` logs nothing at all, success or failure.
Concretely: after re-authing the claude.ai connector, I wanted to confirm whether the resulting calls were using the new PAT pass-through (caller's own Gitea PAT, own identity) or falling through to the existing JWT/shared-token path. The only way to reason about it was inference (a JWT would fail `ValidateToken` against Gitea and fall through) — there was no direct signal in the logs either way.
## Proposed fix
Add one structured log line per successful `/mcp` auth, distinguishing the path taken, e.g.:
```
INFO mcp auth accepted path=passthrough caller=alice token_fp=...
INFO mcp auth accepted path=jwt caller=mathiasbq token_fp=...
INFO mcp auth accepted path=static token_fp=...
```
`token_fp` should be a fingerprint/hash, never the raw token (matches the existing rejection log's `token_fp` convention).
## Acceptance criteria
- A test asserting `PassthroughMiddleware` logs `path=passthrough` with the resolved caller on a successful PAT validation.
- A test (or manual verification) confirming the existing JWT/static success paths in `mcp-chassis`'s `BearerMiddleware` emit an equivalent `path=jwt`/`path=static` accepted line — may require a small `mcp-chassis` change if that library doesn't expose a success hook today.
## Refs
- gitea-mcp#59 (PAT pass-through), v0.12.0/v0.12.1
- gitea-mcp#57/#58 (related: existing rejection-path logging had its own correctness bugs)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
While verifying #59 (v0.12.0/v0.12.1) end to end, I could not confirm from server logs which auth path a given
/mcprequest actually took.chassisauth.BearerMiddlewareonly logs on rejection (mcp auth rejected reason=... status=401);PassthroughMiddlewarelogs nothing at all, success or failure.Concretely: after re-authing the claude.ai connector, I wanted to confirm whether the resulting calls were using the new PAT pass-through (caller's own Gitea PAT, own identity) or falling through to the existing JWT/shared-token path. The only way to reason about it was inference (a JWT would fail
ValidateTokenagainst Gitea and fall through) — there was no direct signal in the logs either way.Proposed fix
Add one structured log line per successful
/mcpauth, distinguishing the path taken, e.g.:token_fpshould be a fingerprint/hash, never the raw token (matches the existing rejection log'stoken_fpconvention).Acceptance criteria
PassthroughMiddlewarelogspath=passthroughwith the resolved caller on a successful PAT validation.mcp-chassis'sBearerMiddlewareemit an equivalentpath=jwt/path=staticaccepted line — may require a smallmcp-chassischange if that library doesn't expose a success hook today.Refs