Add support for new authentication types and Bearer token forwarding#50
Open
Gu-ZT wants to merge 6 commits into
Open
Add support for new authentication types and Bearer token forwarding#50Gu-ZT wants to merge 6 commits into
Gu-ZT wants to merge 6 commits into
Conversation
- 增加 AuthType 配置支持 "authentication" 和 "transform" 两种认证模式 - 在 transform 模式下，服务端从请求上下文中提取变换后的Bearer令牌，转发给上游接口 - 修改各协议客户端调用，优先使用上下文中的变换令牌作为API Key - 在服务端请求分发中，通过上下文传递用户的Bearer令牌替代固定API Key - 新增上下文管理变换认证令牌的函数（存储与提取） - 优化服务器中间件，根据认证类型选择验证策略 - 配置示例中新增 auth_type 选项，支持配置认证模式
- 在配置文件示例中添加 auth_type 字段说明 - 说明两种 Bearer token 处理方式：authentication 与 transform - 在文档中详细说明 auth_type 参数及对应行为 - 举例说明 transform 模式下 token 转发机制 - 在入门文档中新增示例配置及注释说明 auth_type 用法
There was a problem hiding this comment.
Pull request overview
This PR adds a new auth_type server configuration option to support two modes: traditional Bearer-token authentication (authentication, default) and Bearer-token “transform/forwarding” (transform) where the incoming Bearer token is used as the upstream provider credential.
Changes:
- Introduces
auth_typeparsing/storage in config types and loader, plus context plumbing for passing the transformed token through request handling. - Updates server request handling and OpenAI Responses passthrough to use the transformed token as the upstream API key when present.
- Updates Anthropic/OpenAI Chat/Google clients to prefer a transformed token from
context.Context, and updates docs + example config.
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| internal/service/server/server.go | Adds auth_type handling in ServeHTTP and extracts Bearer token into context for transform mode. |
| internal/service/server/dispatch.go | Overrides provider API key with transformed token for OpenAI Responses passthrough. |
| internal/protocol/google/client.go | Uses transformed token (if present) as effective API key for Gemini/Vertex requests. |
| internal/protocol/chat/client.go | Uses transformed token (if present) as effective API key for OpenAI Chat requests. |
| internal/protocol/anthropic/client.go | Uses transformed token (if present) as effective API key for Anthropic requests. |
| internal/config/domain_server.go | Adds AuthType to the server-layer domain config. |
| internal/config/convert.go | Serializes AuthType back into ServerFileConfig for persistence/export. |
| internal/config/config.go | Defines AuthType and context helpers for storing/retrieving transformed tokens. |
| internal/config/config_loader.go | Adds auth_type to file config and parsing into runtime config. |
| docs/GETTING-STARTED.md | Documents auth_type usage in the quickstart config snippet. |
| docs/CONFIGURATION.md | Documents auth_type semantics and how it affects upstream credentialing. |
| config.example.yml | Adds commented examples/explanations for auth_type and auth_token. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- 修改逻辑，排除AuthTypeTransform类型不检查APIKey - 保证其他认证类型必须填写APIKey - 优化配置项校验流程 - 防止认证方式导致的配置错误提示
- 添加resolveWebSearchLazy函数，实现首次请求时根据上下文延迟探测Web搜索支持状态 - 在transform认证模式下，将所有提供者的Web搜索状态标记为"unknown"，推迟探测 - 在请求处理前优先调用延迟探测函数，决定是否启用Web搜索工具注入 - 在app初始化时根据认证类型调整Web搜索状态，避免启动时探测失败
- 在transform认证模式中，将网页搜索状态设置为“unknown”，推迟探测至首次认证请求 - 保留显式配置的启用、禁用及注入优先级 - 避免transform模式下自动探测网页搜索，统一延后处理 - 针对模型级别网页搜索探测，同步调整为延迟处理机制 - 添加对应日志，便于区分普通模式和transform模式行为
- 将解析 AuthType 的函数改为返回错误以便更好地校验配置合法性 - 加入对空白 AuthType 的默认值处理 - 在 transform 模式中，拒绝无 Authorization Bearer Token 的请求并返回 401 错误 - 简化 Bearer Token 的提取逻辑，增强代码可读性和健壮性 - 配置加载时提前验证 AuthType 配置，避免无效配置运行
Owner
|
考虑到MoonBridge支持多提供商，Bearer透传是否考虑作为Per Provider配置而不是全局配置？ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a new "transform" authentication mode, allowing the server to forward the user's Bearer token to upstream providers as the API key, instead of using a configured provider API key. This is useful for proxy scenarios where end users supply their own API keys. The changes include updates to configuration files, documentation, server logic, and provider clients to support this new mode.
Authentication Mode Enhancements
auth_typeconfiguration option (authenticationortransform) to control how Bearer tokens are handled. Intransformmode, the user's Bearer token is extracted and forwarded as the upstream provider's API key. Inauthenticationmode (default), the Bearer token is compared toauth_tokenfor authentication. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]Provider Client Updates
transformmode, falling back to the configured API key otherwise. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16]Documentation and Example Configuration
docs/CONFIGURATION.mdanddocs/GETTING-STARTED.mdto explain the newauth_typeoption and document its usage and effects. The example configuration file now includes comments and examples for both authentication modes. [1] [2] [3]These changes make it possible to securely expose the service as a proxy for end users who supply their own API keys, while maintaining the original authentication mode as the default.