mirror of
https://github.com/BerriAI/litellm.git
synced 2026-09-14 23:21:35 +00:00
40ff01b987
An MCP server behind an API gateway needs two credentials on one request: the gateway's own token on a private header, and a separate bearer on Authorization for the server behind it. Every arm that minted or held a token hardcoded Authorization, and the conflict rule then dropped the operator's static Authorization to make room, so the second credential never arrived. ApiKeyConfig already modelled this as header_name plus value_prefix behind a header() method. Extend that carrier to the four minted-token configs, have each resolver arm ask its config which header to use instead of naming one, and drop only the header the resolved credential is about to occupy. Operators set it per server via upstream_token_header, plumbed through config.yaml, the credentials blob, the management API and the admin form, on the M2M, token-exchange, authorization-code and ID-JAG arms. It is non-secret so it stays plaintext and round-trips on admin reads. Unset keeps today's behaviour. Moving a credential off Authorization means it stops inheriting what Authorization gets for free, so the slot now carries those protections itself. httpx drops Authorization when a redirect crosses origin and keeps every other header, so a custom slot is dropped by the client on the same condition, mirroring httpx's own scheme/host/port rule with an agreement test that fails if the two ever diverge. The v1 path also mirrors the v2 conflict rule, so an injected header cannot shadow the credential the gateway resolved for that slot. Which header a credential occupies, and what counts as being that header, was answered independently in nine places by four hand-rolled comparisons. same_header, has_header and without_header in litellm/types/mcp.py are now the one owner, shared by both MCP stacks, and the client derives its slot once instead of three times. The header name reaches egress verbatim, so the RFC 7230 grammar lives in one place and is checked where servers are built: a bad value fails the config load and the management API returns 400, rather than raising while a spec is built and emptying the aggregate tool list for every other server. A blank means unset, matching what the endpoint already accepts. |
||
|---|---|---|
| .. | ||
| public | ||
| scripts | ||
| src | ||
| tests | ||
| .env.development | ||
| .env.production | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| build_release_ui.sh | ||
| build_ui.sh | ||
| build_ui_custom_path.sh | ||
| CLAUDE.md | ||
| components.json | ||
| eslint-budgets.json | ||
| eslint-suppressions.json | ||
| eslint.config.mjs | ||
| knip.json | ||
| next.config.mjs | ||
| package-lock.json | ||
| package.json | ||
| postcss.config.js | ||
| README.md | ||
| tsconfig.json | ||
| tsconfig.tsbuildinfo | ||
| vitest.config.ts | ||
This is a Next.js project bootstrapped with create-next-app.
Getting Started
First, run the development server:
npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev
Open http://localhost:3000 with your browser to see the result.
You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.
This project uses next/font to automatically optimize and load Inter, a custom Google Font.
Learn More
To learn more about Next.js, take a look at the following resources:
- Next.js Documentation - learn about Next.js features and API.
- Learn Next.js - an interactive Next.js tutorial.
You can check out the Next.js GitHub repository - your feedback and contributions are welcome!
Deploy on Vercel
The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.
Check out our Next.js deployment documentation for more details.