3 Commits

Author	SHA1	Message	Date
Aari	340bff1107	feat(mcp): manage servers from Settings (#5022) ... * feat(mcp): manage servers from settings * fix(mcp): make settings updates targeted * fix(mcp): reject ambiguous masked array edits * fix(mcp): honor targeted server field deletions * fix(mcp): preserve OAuth extension secrets * fix(mcp): validate config before persistence * fix(mcp): preserve environment placeholders * fix(mcp): harden targeted configuration routes * docs: keep gateway guidance within budget * fix(mcp): protect per-tool override secrets * fix(mcp): keep disabled edits structurally safe	2026-09-01 23:24:49 +08:00
Terminator666666	c17aa8b98f	fix(mcp): reject credentials that cannot travel as HTTP header values (#5066) ... * fix(mcp): reject credentials that cannot travel as HTTP header values A request-scoped secret or user_auth credential with a trailing newline (the usual result of reading a token from a file, or a CRLF env-file), CR/LF, surrounding whitespace, or characters outside Latin-1 sailed through the credential interceptors into the HTTP client, where httpx/h11 reject it with an exception that echoes the full value: LocalProtocolError: Illegal header value b'Bearer sk-...\n' ToolErrorHandlingMiddleware copies that message into a model-visible ToolMessage, so the secret landed in the prompt, the checkpoint, and traces - everywhere headers_from_context promises it never goes. Add illegal_header_value_reason to mcp/headers.py, mirroring the transport's own rules (Latin-1 encodable; h11's field_vchar is [^\x00\s] with SP/HTAB legal only between visible characters), and fail closed in both interceptors before the value can reach the client. The denial names only the secret key (plus the reason) and never repeats the value. Illegal values are denied regardless of on_missing: the key is present, so a passthrough fallback would silently run the call under the shared discovery credential - the exact authority confusion the deny default exists to prevent. Values the transport accepts are not rejected: embedded SP/HTAB ('Bearer <token>'), Latin-1 high bytes, and DEL all still pass, pinned by tests against h11's observed behaviour. * fix(mcp): tighten header value validation to httpx's ASCII boundary The validator mirrored h11's Latin-1 boundary, but the transport rejects more than h11 does: build_server_params hands dict[str, str] headers through the MCP SDK's create_mcp_http_client into httpx.AsyncClient, and httpx (pinned 0.28.1) encodes str header values as ASCII - so a Latin-1 high byte like 'Bearer caf\xe9' passed validation here only to raise UnicodeEncodeError inside httpx before h11 ever ran, with the exception message repeating the offending value. Validate str values against ASCII instead, flip the tests that pinned Latin-1 high bytes as transportable, and pin the boundary against the real client: create_mcp_http_client must reject what the validator flags and construct cleanly for what it accepts (embedded SP/HTAB and DEL still pass). Addresses review feedback on the ASCII vs Latin-1 boundary. * fix(mcp): validate OAuth and static header values at the same boundary The validator added for headers_from_context and user_auth left two paths uncovered. A token endpoint returning an access_token or token_type with a newline reached httpx/h11, which raise with the full token in the message, and ToolErrorHandlingMiddleware copies that message into a model-visible ToolMessage -- the leak this PR set out to close. The operator's static headers had the same hole. OAuthTokenManager.get_authorization_header now renders the Authorization value through one checked helper, so the tool interceptor, the initial discovery headers and the durable task path are all covered by a single guard. The rendered value is what gets checked rather than the two fields separately, because that is what the transport sees: an access_token with leading whitespace is legal once it follows "Bearer ". build_server_params applies the same check to statically configured headers. build_servers_config already isolates a per-server failure, so a bad value drops that one server and logs the reason instead of the value. * docs(mcp): correct which transport echoes the full header value The rationale claimed httpx and h11 both render the full value into their exception message. Only h11 does, on the line break and surrounding whitespace cases. httpx's ASCII failure is a UnicodeEncodeError naming the offending character and its position, not the credential, so at most one character escapes there; refusing the value up front buys an actionable error rather than an encode failure raised from inside the client. Corrected in headers.py and in every copy of the claim: context_headers.py, user_scoped_auth.py, oauth.py, client.py, mcp/AGENTS.md, docs/MCP_SERVER.md, the frontend mcp.mdx, and the test comments carrying the same wording. No behavior change. --------- Co-authored-by: Terminator666666 <Terminator666666@users.noreply.github.com>	2026-08-31 15:07:30 +08:00
青榆牧	a94b2d8897	feat(mcp): map request-scoped secrets to MCP HTTP/SSE headers (#5010) ... * feat(mcp): map request-scoped secrets to HTTP/SSE headers `user_auth` binds a credential to a configured DeerFlow user, so a caller that picks the credential per request — a multi-tenant gateway, a per-run API key, one shared MCP server fronting several environments — had to register one MCP server entry per credential. Add a declarative `mcpServers.<server>.headers_from_context` block mapping HTTP header names to keys of the run request's `config.context.secrets` carrier. A new built-in interceptor resolves the mapping on every tool call and rewrites those headers, mirroring `user_scoped_auth`. The config file stores names only, never a credential, so the Gateway returns the block unmasked. Registered after OAuth and `user_auth` in the interceptor chain: the later interceptor runs closer to the transport, and the value chosen for this one request is the most specific, so it wins. Fail-closed by default — a mapped key missing from the request raises a `ToolException` naming only that key, because falling back to the server's discovery credential would send one tenant's call under another tenant's authority. `on_missing: "passthrough"` opts out. Durable background tasks are excluded: `McpTaskToolCaller` drives status and cancel polls after the Agent run ends, where no run context exists, so the fail-closed interceptor would deny every poll. Those calls keep using server-level credentials, and a server declaring both `headers_from_context` and `task_toolsets` now logs a warning. Also corrects the custom-interceptor example in docs/MCP_SERVER.md (and the matching claim in skills/AGENTS.md), which read request secrets from `langgraph.config.get_config()["context"]`. That key is `None` inside a tool call — the run context rides the LangGraph runtime, not the RunnableConfig propagated to child runnables — so interceptors written from that example never saw a value. The example now reads `request.runtime`, and tests/test_mcp_context_headers.py pins LangGraph's runtime-injection rule by driving a real langchain-mcp-adapters tool through a real graph with the ambient-runtime fallback disabled. Closes #5005 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(mcp): resolve credential headers case-insensitively, carry them on durable submit Review follow-ups on `headers_from_context`. HTTP field names are case-insensitive, but every dict on the path to the wire is not: `build_server_params` copies the operator's static `headers` spelling verbatim, and langchain-mcp-adapters merges interceptor overrides into the connection with a plain `{**connection_headers, **override_headers}` splat. A static `authorization` and an injected `Authorization` therefore both reached httpx as separate field lines, and a server reading the field with a single-value accessor got the static discovery credential — inverting the documented `headers` < `oauth` < `user_auth` < `headers_from_context` precedence and running a per-request call under the shared credential. Normalizing inside the interceptor cannot fix that on its own: the adapter builds the request with `headers=None`, so an interceptor never sees the connection's static headers and cannot displace them however it spells its own key. A new `mcp/headers.py::apply_header_overrides` therefore drops any key differing only in case and emits the spelling the connection already uses. Applied to `headers_from_context`, `user_auth`, the OAuth interceptor, the OAuth discovery-header write, and the durable-task connection merge, which all carried the same collision. `headers_from_context.headers` now also rejects one header mapped under two spellings at config load, in both the harness model and the Gateway mirror. Durable submit now carries the mapped headers, as docs/MCP_SERVER.md already promised. `McpTaskToolCaller` disabled the interceptor for the whole caller, but that caller serves submit as well as the polls, and submit is awaited inline inside the Agent's tool call — where the run's LangGraph runtime is still the ambient contextvar, so no secret has to be threaded through `TaskSubmitRequest` or reach durable storage. The caller builds one chain and keeps a second view of it without the context-headers interceptor; `call_tool` takes `request_scoped_headers`, set only by `OrdinaryMcpTaskDriver.submit`. Status and cancel keep server-level credentials, so background polls still cannot fail closed, and the startup warning now describes the half it actually covers. `_merge_preserving_secrets` restores masked extras inside `headers_from_context` instead of writing the `***` sentinel back over the stored value, matching the treatment `user_auth` extras and server-level extras already get; extras a PUT omits carry over as well, while the declared mapping still replaces verbatim so a round trip can remove an entry. `extra="allow"` plus name-based sensitivity detection means the usual casualty is a name-valued key such as `tokenHeader`, not only a credential. The existing override test seeded the static header onto `request.headers`, which production never does, so it modelled a merge that really happens one layer down; the new tests drive a real adapter tool through a real connection and assert on the headers the session is opened with, and the durable-submit test runs through a real tool node with no runtime patching. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(mcp): reject case-insensitive duplicate static header names * fix(mcp): preserve omitted headers_from_context fields on partial updates --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 10:42:42 +08:00