Ivan-Apro dffd27f883 🎫 fix: Forward User Auth Headers on Model Fetch (#13616) ...

* 🔐 fix: Resolve template vars and respect custom Authorization on model fetch

The custom-endpoint model fetch path in `fetchModels` had two bugs that
silently broke per-user authentication on `GET /v1/models`:

1. Template variables in the configured `headers:` block were not
   substituted on the OpenAI-compatible branch. Only the Ollama branch ran
   `resolveHeaders`, so placeholders like `{{LIBRECHAT_OPENID_ID_TOKEN}}`
   were forwarded as literal strings on every other endpoint.
2. After spreading the (unresolved) headers into the request, the code
   unconditionally executed
   `options.headers.Authorization = \`Bearer ${apiKey}\`` and clobbered any
   `Authorization` the operator had set in `headers:`.

Combined, these meant a config like
```yaml
endpoints:
  custom:
    - name: "MyProxy"
      apiKey: "${MY_API_KEY}"
      headers:
        authorization: "Bearer {{LIBRECHAT_OPENID_ID_TOKEN}}"
```
sent `Authorization: Bearer ${MY_API_KEY}` on `/v1/models` instead of the
user's resolved JWT — even with `OPENID_REUSE_TOKENS=true` set. Auth-aware
proxies (e.g. LiteLLM with team-based JWT auth) therefore could not return
a per-user filtered model list.

This change runs `headers` through `resolveHeaders` (mirroring the Ollama
branch) and only falls back to the apiKey-based default when the resolved
headers do not already supply an `Authorization` (case-insensitive). All
other endpoints behave unchanged: when no `Authorization` is configured,
the existing `Bearer ${apiKey}` default still applies.

Tests added:
- Template variables in custom headers are resolved on the OpenAI path.
- A config-supplied `Authorization` overrides the apiKey default.
- The override check is case-insensitive (`authorization` works too).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* 🔐 fix: Address review — import order, P1 token leak guard, P2 token-config path

- Fix sort-imports drift in `models.ts` and `custom/initialize.ts`.
- P1: in `loadConfigModels` (`config/models.ts`), do not forward
  `endpointHeaders` to `fetchModels` when `baseURLIsUserProvided`.
  Configured templates such as `Authorization: Bearer
  {{LIBRECHAT_OPENID_ID_TOKEN}}` would otherwise resolve and be sent to a
  destination the user controls — leaking the user's identity token.
  Header overrides remain in place when only the apiKey is user-provided
  (admin-trusted base URL).
- P2: in `initializeCustom` (`custom/initialize.ts`), the token-config
  fetch path now forwards `headers` and `userObject` to `fetchModels`
  (mirroring the auth-aware behaviour), with the same `userProvidesURL`
  guard. Additionally, when `endpointConfig.headers` is set the model
  cache is skipped to avoid a per-user filtered response leaking across
  users; token-config caching was already user-keyed when key/URL are
  user-provided.

Tests added:
- `config/models.spec.ts` (new): verifies the P1 guard — headers are
  dropped when the base URL is user-provided, and forwarded when only the
  apiKey is user-provided.
- `custom/initialize.spec.ts`: three cases for the P2 path covering header
  forwarding to admin-trusted base URLs, header drop on user-provided
  base URLs, and absence of `skipCache` when no headers are configured.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* 🔐 fix: Scope model + token-config caches when user-bound headers are forwarded

Two follow-up fixes from the second review pass:

P1.1 (`fetchModels` / `models.ts`): the MODEL_QUERIES cache is keyed by
baseURL+apiKey only. When callers forward headers containing template
variables that resolve against the current user (e.g. `Authorization:
Bearer {{LIBRECHAT_OPENID_ID_TOKEN}}`), one user's filtered list could be
served to the next request that happens to share the same baseURL+apiKey.
`shouldCache` now skips the cache whenever both `headers` and `userObject`
are supplied — that's the unambiguous signal the response is being
resolved against a specific user identity. Existing callers that pass
neither (fetchOpenAIModels, fetchAnthropicModels) keep their cache.

P1.2 (`initializeCustom` / `custom/initialize.ts`): the surrounding
tokenConfigCache uses `tokenKey === endpoint` when key+URL are
admin-configured. With user-bound headers forwarded, the first user's
token config could be cached for the shared endpoint and served to other
users until TTL. `tokenKey` is now also user-scoped when
`endpointConfig.headers` will be forwarded (i.e. base URL is
admin-trusted, so the security guard leaves headers in place).

Also removed the explicit `skipCache: !!endpointConfig.headers` from the
fetchModels call in initializeCustom — the new fetchModels-level rule
covers it uniformly across both call sites.

Tests added:
- models.spec.ts: cache skipped on `headers + userObject`; cache used
  when only one of them is supplied (existing callers unaffected).
- initialize.spec.ts: `tokenKey` is `${endpoint}:${userId}` when headers
  will be forwarded, and `endpoint` (unscoped) when no headers are
  configured.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* 🔐 fix: Include header fingerprint in in-request model fetch coalescing key

`loadConfigModels` coalesces concurrent fetches for endpoints that share
the same admin-trusted `${BASE_URL}__${API_KEY}` via `fetchPromisesMap`.
With per-endpoint `headers:` overrides — including templates that resolve
against the current user — that key is too coarse: two custom endpoints
sharing a proxy URL/key but configuring different headers (e.g. distinct
`X-Tenant` values, or different static `Authorization` strings) would
share a single fetch promise, and the first endpoint's filtered response
would be returned for the second endpoint within the same request.

Fix: include a stable SHA-256 fingerprint of the configured headers in
the coalescing key. Endpoints that genuinely share `baseURL + apiKey +
headers` still share one fetch (preserves the existing optimisation);
endpoints that differ in headers each get their own fetch.

Test added in `config/models.spec.ts`:
- Two endpoints sharing baseURL+apiKey but with different headers result
  in two `fetchModels` calls, each carrying the right headers.
- Two endpoints sharing baseURL+apiKey AND identical headers still
  coalesce into a single `fetchModels` call.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-06-10 15:22:17 -04:00

..

api

🎫 fix: Forward User Auth Headers on Model Fetch (#13616)

2026-06-10 15:22:17 -04:00

client

…

data-provider

…

data-schemas

…