fix(anthropic): support bearer key auth for gateways - #595
Conversation
Use apiKeyTransport when building Anthropic key-auth requests and normalize Anthropic model discovery URLs so /v1 base URLs do not become /v1/v1/models.
📝 WalkthroughWalkthroughAnthropic provider configuration now supports selectable ChangesAnthropic authentication routing
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant ProviderConfig
participant ProviderUI
participant ManagementAPI
participant RequestBuilder
participant AnthropicAPI
ProviderUI->>ManagementAPI: submit apiKeyTransport
ManagementAPI->>ProviderConfig: validate and persist setting
ProviderConfig->>RequestBuilder: provide auth mode and transport
RequestBuilder->>AnthropicAPI: send x-api-key or Authorization Bearer
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 `@src/types.ts`:
- Around line 876-881: Propagate the `apiKeyTransport` option from the
credential configuration into `KeyLoginProvider`, and update its Anthropic
validation request to select `x-api-key` or `Authorization: Bearer` consistently
with `createAnthropicAdapter` and `buildModelsRequest`. Add a regression test
covering bearer-based key validation while preserving native header behavior by
default.
🪄 Autofix (Beta)
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: ASSERTIVE
Plan: Pro Plus
Run ID: 88efee9c-3a54-4774-82dc-17e6158d0fc0
📒 Files selected for processing (5)
src/adapters/anthropic.tssrc/oauth/index.tssrc/types.tstests/google-models-listing.test.tstests/umans-provider.test.ts
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4ff653577b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| * Defaults to the native Anthropic `x-api-key`; gateways may require | ||
| * `Authorization: Bearer <key>` instead. | ||
| */ | ||
| apiKeyTransport?: "x-api-key" | "bearer"; |
There was a problem hiding this comment.
This introduces apiKeyTransport as a user-facing provider config field that bearer-only Anthropic gateways now rely on, but the commit does not update docs-site/ (and rg apiKeyTransport docs-site has no hits). Users following the configuration reference will still have no documented way to discover that setting apiKeyTransport: "bearer" fixes these gateway 401s, so please add the option and keep the localized docs in sync.
AGENTS.md reference: AGENTS.md:L96-L97
Useful? React with 👍 / 👎.
| headers["x-client-request-id"] = crypto.randomUUID(); | ||
| } else { | ||
| headers["x-api-key"] = provider.apiKey; | ||
| if (anthropicKeyUsesBearer(provider)) headers["Authorization"] = `Bearer ${provider.apiKey}`; |
There was a problem hiding this comment.
This branch only activates when the saved provider already has apiKeyTransport: "bearer", but the normal Dashboard/CLI setup paths still cannot set that field (buildProviderPayload has no payload member and ocx provider edit has no option, while an apiKeyTransport-only PATCH is unrecognized). For an Anthropic-compatible gateway added through those supported flows, the provider is saved without the flag and requests continue to send x-api-key, so the 401 this patch targets remains unless the user hand-edits config; please wire the field through provider setup/edit or seed it for affected gateways.
Useful? React with 👍 / 👎.
| headers["x-client-request-id"] = crypto.randomUUID(); | ||
| } else { | ||
| headers["x-api-key"] = provider.apiKey; | ||
| if (anthropicKeyUsesBearer(provider)) headers["Authorization"] = `Bearer ${provider.apiKey}`; |
There was a problem hiding this comment.
This line changes how a provider API key is serialized into upstream authentication headers for Anthropic-compatible providers, so it falls under the repository security boundary for authentication and credential/token handling changes. I don't see explicit security-review evidence in this commit; please record that review/signoff before merging this auth-path change.
AGENTS.md reference: AGENTS.md:L83-L87
Useful? React with 👍 / 👎.
Carry apiKeyTransport through key-login provider derivation and use the same bearer vs x-api-key selection during Anthropic API-key validation.
|
Addressed the remaining setup and documentation feedback for Changes:
Validation run locally:
Note: the remaining security-review/signoff request is a maintainer process item for the auth-header change, not something code can self-certify. |
|
Follow-up CI fix pushed in It addresses the check failures from the previous run:
Focused validation run locally after the fix:
|
Maintainer review — bug + security (
|
| Source | Item | Status on tip |
|---|---|---|
| CodeRabbit | Propagate apiKeyTransport through key validation |
Resolved — key-providers.ts + bearer validation test landed in 24c71bba |
| Codex P2 | Document apiKeyTransport in docs-site |
Stale / fixed — EN + zh-CN/ja/ko/ru configuration + adapters docs in fbcc8311 |
| Codex P2 | Expose via Dashboard/CLI/management PATCH | Stale / fixed — GUI selector, ocx provider add/edit --api-key-transport, POST/PATCH validation in fbcc8311 |
| Codex P1 | Security review for auth-header change | Done below |
Please resolve the three remaining Codex threads; they no longer describe tip.
Security (auth boundary)
Scoped to this PR’s credential path (apiKeyTransport → Anthropic key auth headers):
- Transport restricted to Anthropic + key auth (config Zod, management, CLI); OAuth path unchanged
- Key mode sends either
x-api-keyorAuthorization: Bearer, not both SENSITIVE_PROVIDER_HEADERSstill blocks auth-header override viaprovider.headers- No new key/token logging; GET responses expose transport mode only
No medium+ security findings in #595. (A loopback Host-gate note from review tooling is out of scope here — that is already on dev via #573, not this diff.)
Bug review
No merge-blocking functional defect for the stated goals (bearer gateways + /v1 models URL normalize + setup/docs).
One latent consistency note (not a tip bug today — no registry preset currently seeds apiKeyTransport: "bearer"):
enrichProviderFromRegistrybackfillsapiKeyTransport, butroutedProviderConfigdoes not. If a future preset seeds bearer and a persisted provider omits the field, catalog/models enrichment could use Bearer while live routed turns still default tox-api-key. Optional follow-up: mirror thegoogleMode-style backfill insrc/router.ts.
Summary
Ship it. Author already closed the actionable Rabbit/Codex code gaps; security signoff recorded for the auth-header change.
|
Thanks for the PR — nice fix for Anthropic-compatible gateways (bearer transport + |
Summary
apiKeyTransportin the Dashboard, provider API, and CLI; document the option./v1base URLs when discovering Anthropic models.Validation
bun run typecheckbun run lint:guibun run privacy:scanbun run test(5610 pass, 0 fail)cd gui && bun test && bun run build && bun run lint