fix(auth): get_access_token reflects current request in stateful sessions - #2675
Conversation
There was a problem hiding this comment.
2 issues found across 3 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/mcp/server/runner.py">
<violation number="1" location="src/mcp/server/runner.py:231">
P2: Notification handlers in a stateful Streamable HTTP session can still read the session-creating request's token after a later authenticated notification. Scope `push_auth_context_from_request(ctx.request)`/`pop_auth_context()` around `_on_notify`'s middleware call too, so `get_access_token()` matches that notification's HTTP request.</violation>
</file>
<file name="tests/server/auth/test_get_access_token_streamable_http.py">
<violation number="1" location="tests/server/auth/test_get_access_token_streamable_http.py:66">
P2: This regression test creates and terminates a separate Streamable HTTP session for each token, so it passes even with the original stale-context bug. Keeping one `streamable_http_client`/`Client` open while changing the mutable auth token between tool calls would exercise later HTTP requests on the same stateful session.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| # including its response envelope. The pipeline never patches it up after | ||
| # the fact. | ||
| result = _dump_result(await call(ctx)) | ||
| auth_token = push_auth_context_from_request(ctx.request) |
There was a problem hiding this comment.
P2: Notification handlers in a stateful Streamable HTTP session can still read the session-creating request's token after a later authenticated notification. Scope push_auth_context_from_request(ctx.request)/pop_auth_context() around _on_notify's middleware call too, so get_access_token() matches that notification's HTTP request.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/mcp/server/runner.py, line 231:
<comment>Notification handlers in a stateful Streamable HTTP session can still read the session-creating request's token after a later authenticated notification. Scope `push_auth_context_from_request(ctx.request)`/`pop_auth_context()` around `_on_notify`'s middleware call too, so `get_access_token()` matches that notification's HTTP request.</comment>
<file context>
@@ -227,7 +228,11 @@ async def _inner(ctx: ServerRequestContext[LifespanT, Any]) -> HandlerResult:
# including its response envelope. The pipeline never patches it up after
# the fact.
- result = _dump_result(await call(ctx))
+ auth_token = push_auth_context_from_request(ctx.request)
+ try:
+ result = _dump_result(await call(ctx))
</file context>
| follow_redirects=True, | ||
| ) as http_client, | ||
| ): | ||
| transport_ctx = streamable_http_client(f"http://{host}/mcp", http_client=http_client) |
There was a problem hiding this comment.
P2: This regression test creates and terminates a separate Streamable HTTP session for each token, so it passes even with the original stale-context bug. Keeping one streamable_http_client/Client open while changing the mutable auth token between tool calls would exercise later HTTP requests on the same stateful session.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At tests/server/auth/test_get_access_token_streamable_http.py, line 66:
<comment>This regression test creates and terminates a separate Streamable HTTP session for each token, so it passes even with the original stale-context bug. Keeping one `streamable_http_client`/`Client` open while changing the mutable auth token between tool calls would exercise later HTTP requests on the same stateful session.</comment>
<file context>
@@ -0,0 +1,97 @@
+ follow_redirects=True,
+ ) as http_client,
+ ):
+ transport_ctx = streamable_http_client(f"http://{host}/mcp", http_client=http_client)
+ async with Client(transport_ctx) as client: # pragma: no branch
+ result = await client.call_tool("whoami", {})
</file context>
Fixes #2208.
Stateful Streamable HTTP sessions start the server task group on the first request. Anyio copies the request contextvars into that long-lived task, so get_access_token() could keep returning the token from the session-creating request even when later requests send a different Authorization header.
This change pushes the authenticated user into the auth contextvar at request-dispatch time (using the ServerMessageMetadata.request_context threaded through the transport), and resets it after the handler returns.
Tests: