fix(openai-compat): resolve alias for header-only auth#4081
fix(openai-compat): resolve alias for header-only auth#4081GreenTeodoro839 wants to merge 2 commits into
Conversation
|
This pull request targeted The base branch has been automatically changed to |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces logic to identify OpenAI-compatible providers and classify their authentication as API-key authentication. It adds the IsOpenAICompatibleProvider helper in internal/util and updates the classification logic in sdk/cliproxy/auth. The review feedback suggests simplifying the isOpenAICompatibilityAuth function by using the existing authAttribute helper to retrieve the compat_name attribute, which automatically handles nil checks and string trimming.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| if a.Attributes != nil && strings.TrimSpace(a.Attributes["compat_name"]) != "" { | ||
| return true | ||
| } | ||
| return false |
There was a problem hiding this comment.
在 isOpenAICompatibilityAuth 函数中，可以直接使用已有的 authAttribute 辅助函数来获取 compat_name 属性。\n\nauthAttribute 内部已经安全地处理了 auth 和 auth.Attributes 的 nil 检查，并自动进行了 strings.TrimSpace。使用它可以简化代码并提高可维护性。
\treturn authAttribute(a, \"compat_name\") != \"\"There was a problem hiding this comment.
Pull request overview
This PR fixes a gap in OpenAI-compat model-alias resolution when an upstream authenticates via custom headers (no api_key), by ensuring such auth entries are still classified as API-key style credentials so the alias/pool logic applies.
Changes:
- Teach
AuthKind()to treat OpenAI-compatibility auth entries (provider key and/orcompat_name) asapikeyauth kind. - Add
util.IsOpenAICompatibleProvider()helper to centralize provider-key detection for OpenAI-compatibility providers.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| sdk/cliproxy/auth/classification.go | Extends auth-kind classification so OpenAI-compat header-only auths participate in alias resolution. |
| internal/util/provider.go | Adds a helper to recognize OpenAI-compatibility provider keys (generic and prefixed forms). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if isOpenAICompatibilityAuth(a) { | ||
| return AuthKindAPIKey | ||
| } | ||
| if authHasOAuthMetadata(a) { | ||
| return AuthKindOAuth | ||
| } |
| if a.Attributes != nil && strings.TrimSpace(a.Attributes["compat_name"]) != "" { | ||
| return true | ||
| } |
| // OpenAI-compatibility providers always use static credentials: either an API | ||
| // key or custom headers (e.g. cookie/device headers) when no api-key is set. | ||
| // Treat them as API-key auths so model-alias resolution and per-auth model | ||
| // pools apply even for header-authenticated entries. | ||
| if isOpenAICompatibilityAuth(a) { |
| func IsOpenAICompatibleProvider(provider string) bool { | ||
| provider = strings.ToLower(strings.TrimSpace(provider)) | ||
| if provider == "" { | ||
| return false | ||
| } |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7c44826951
ℹ️ 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".
| if util.IsOpenAICompatibleProvider(a.Provider) { | ||
| return true |
There was a problem hiding this comment.
When an auth is identified only by its normalized provider key (for example Provider: "openai-compatible-vast") and has no compat_name/provider_key attributes, this branch now classifies it as an API-key auth, but the API-key alias/pool path still looks up OpenAI-compat config via those attributes or by comparing the raw provider string in resolveOpenAICompatConfig. Since that lookup never strips the openai-compatible- prefix to match a config named vast, these header-only provider-key auths still forward client aliases upstream while also skipping the OAuth alias fallback. Please derive the compat name/provider key from the prefix here or update the resolver to handle the normalized provider key.
Useful? React with 👍 / 👎.
GreenTeodoro839
force-pushed
the
fix/openai-compat-header-alias-resolution
branch
from
f35c609 to
2364fdf
Compare
OpenAI-compatibility providers that authenticate via custom headers (no api_key) had AuthKind() return empty, causing the entire model-alias resolution chain to skip. The client-visible alias was forwarded to the upstream verbatim, resulting in 'Not supported model' errors. Add IsOpenAICompatibleProvider() helper and teach AuthKind() to recognize openai-compat auths as API-key auths, enabling alias resolution for both api-key and header-authenticated entries.
GreenTeodoro839
force-pushed
the
fix/openai-compat-header-alias-resolution
branch
from
2364fdf to
0afcca3
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0afcca357e
ℹ️ 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".
| if isOpenAICompatibilityAuth(a) { | ||
| return AuthKindAPIKey |
There was a problem hiding this comment.
For OpenAI-compatible auth files that include an email field only as a label/account identifier, authHasOAuthMetadata returns OAuth before this new provider check can run, so a header-only openai-compatible-* auth is still excluded from the API-key alias/pool path this change is meant to enable. The file synthesizer preserves arbitrary email metadata for any provider, so these header-auth entries continue forwarding client aliases upstream unless the OpenAI-compatible/provider check runs before the legacy OAuth metadata fallback (while still letting explicit auth_kind: oauth win).
Useful? React with 👍 / 👎.
GreenTeodoro839
force-pushed
the
fix/openai-compat-header-alias-resolution
branch
2 times, most recently
from
e759e7b to
0afcca3
Compare
修复openai completion某些极端情况下（例如上游使用header鉴权而不用key），alias会直接透传到上游而没有被替换成真实的name
OpenAI-compatibility providers that authenticate via custom headers (no api_key) had AuthKind() return empty, causing the entire model-alias resolution chain to skip. The client-visible alias was forwarded to the upstream verbatim, resulting in 'Not supported model' errors.
Add IsOpenAICompatibleProvider() helper and teach AuthKind() to recognize openai-compat auths as API-key auths, enabling alias resolution for both api-key and header-authenticated entries.