feat(server): forward inbound Anthropic auth - #372
Conversation
|
WalkthroughThe change adds ChangesAnthropic authentication forwarding
Estimated code review effort: 3 (Moderate) | ~25 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/libsy-llm-client/README.md`:
- Around line 216-220: Update the HttpBackendConfig::forward_auth documentation
to explicitly scope credential and anthropic-beta forwarding behavior to
Anthropic backends, particularly anthropic_messages clients, and clarify that it
does not apply to OpenAI backends.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 40554ecd-43d1-4be7-ac4e-166ad0b5b978
📒 Files selected for processing (8)
crates/libsy-llm-client/README.mdcrates/libsy-llm-client/src/backend.rscrates/libsy-llm-client/src/client.rscrates/switchyard-server/README.mdcrates/switchyard-server/src/config.rscrates/switchyard-server/tests/server.rsdocs/getting_started.mddocs/reference/toml_schema.md
Signed-off-by: Elyas Mehtabuddin <emehtabuddin@nvidia.com>
Signed-off-by: Elyas Mehtabuddin <emehtabuddin@nvidia.com>
4de6f1b to
12b1ea1
Compare
When Claude Code sends an
Authorizationheader orx-api-keytoPOST /v1/messages, currentmaindoes not copy that header to the Anthropic request. A local upstream server recorded:{"authorization_forwarded": false}Fix
Add
forward_auth = trueto the Anthropic client:With the setting enabled, Switchyard copies the caller's
Authorizationorx-api-keyheader to the Anthropic request. For Claude subscription sign-in, it also copiesoauth-*entries fromanthropic-beta. Other caller-supplied beta entries still do not reach the upstream server.forward_authdefaults tofalse, so configs that omit it do not start copying request credentials. The server accepts it only foranthropic_messagesclients. It rejects configs that also setapi_key_envor putAuthorizationorx-api-keyinextra_headers, because those settings would give Switchyard two sources for the same credential.Proof
I pointed Claude Code at the branch server and sent a dummy bearer token to a local Anthropic-compatible server. The local server returned HTTP 200 only when it received that bearer token:
origin/mainat224287bcsent the same dummy bearer request without anAuthorizationheader:Live external test
I also ran Claude Code through the branch server to an external Anthropic Messages endpoint. Claude Code returned:
GET /v1/statsrecorded one request and no errors:The API key was supplied through an environment variable and sent as a bearer token. Its value does not appear in the config, command output, server stats, or this PR description.
This run checks live bearer-token forwarding. It does not check Claude subscription OAuth because Claude Code was not signed in to a subscription on this machine. The local test above checks the
oauth-*beta header with a dummy token.Tests
anthropic_client_forwards_inbound_auth_when_configuredsends two requests through Switchyard's/v1/messagesrouter to a local Anthropic server. It checks bothAuthorizationandx-api-key, checks the requiredanthropic-versionheader, and checks that only theoauth-*beta entry reaches the upstream server.forward_auth_rejects_unsupported_configurationschecks the three rejected config combinations described above.Closes #164