feat(platform): support channel-key header for dedicated cloud channels#141
Merged
Conversation
专属云渠道用户(复用主站域名,如 api.ucloud-global.com)调用 API 报校验错误: 网关需要 channel-key 请求头来定位「去哪个渠道的用户库查验凭据」,缺失时 AK/SK 报 171 Signature VerifyAC Error、OAuth 报 174 Token Not Exists。 新增 profile 级可选配置 channel_key(落 config.json,omitempty),经 attachHandlersWithManager 这一唯一汇聚点注入,覆盖全部 client 构造路径。 - config.go: channel_key 配置项、--channel-key 全局 flag 字段、mergeConfigIns 覆盖、--config 表格新增 ChannelKey 列(渠道标识非凭据,不脱敏) - client.go: newChannelHeaderInjector,与凭据注入并列而非并入——channel-key 是 接入点配置(同 base_url),与 auth_mode 正交,不属 spec「一个请求只携带一种 凭据机制」的约束对象 - root.go: --channel-key 全局 flag(os.Args 扫描 + 注册,缺一不可) - configure.go: config / config add / config update 三处入口,与 base-url 对齐; channel-key 归入「连接类参数」并早于远程校验应用,否则专属云 profile 会陷入 「配置时校验即 171 → 永远配不上」的死锁 空值完全不注入该头(键不存在,而非空值),保证主站与独立域名渠道用户线路字节 零变化——刻意区别于同文件 Cookie/Csrf-Token「空值也照旧 set」的存量契约。 真实 combo 账号 + 真实网关实测:AK/SK 171→0、OAuth 174→0;Go 规范化后的 Channel-Key 网关照常接受;config add 一步建 profile 可用。 已知局限(继承自 --base-url,非本次引入):os.Args 扫描只认 --channel-key X 空格形式,--channel-key=X 静默失效。 另记录:channel-key 不匹配时网关同样返回 174,与 token 过期同码,会使既有的 authRetCodeWhitelist 误触发一轮刷新+重放。已在 client.go 注释留档,本次不改 控制流。
|
🔴 平台 PR 默认硬拦,需管理员 Approve 放行(或由管理员提交)。判定:改动触及平台/受保护路径(cmd/configure.go, cmd/internal/platform/client.go, cmd/internal/platform/client_test.go, cmd/internal/platform/config.go, cmd/internal/platform/config_test.go, cmd/root.go, hack/snapshot/testdata/cmdtree.golden) |
Ali1213
enabled auto-merge
July 17, 2026 05:57
Ali1213
disabled auto-merge
July 17, 2026 05:59
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.
背景
专属云渠道用户(复用主站 API 域名的渠道)调用 API 报校验错误。网关需要
channel-key请求头来定位「去哪个渠道的用户库查验凭据」,缺失时:RetCode 171 Signature VerifyAC Error(即用户报障的「校验错误」)RetCode 174 Token Not ExistsCLI 此前没有任何 channel 概念(全库无相关实现),故这类用户无法使用 CLI 做日常操作。
改动
新增 profile 级可选配置
channel_key(落config.json,omitempty),在attachHandlersWithManager这一唯一汇聚点注入,因而覆盖全部 client 构造路径:products 的cli.NewServiceClient、api命令、config 子命令的远程校验、以及AttachHandlers。config.gochannel_key配置项、全局 flag 字段、mergeConfigIns覆盖、--config新增 ChannelKey 列client.gonewChannelHeaderInjector+ 挂载root.go--channel-key全局 flag(os.Args 扫描 + 注册)configure.goconfig/config add/config update三处入口,与base-url对齐核心逻辑 77 行,其余为测试。
关键设计
独立 handler,不并入
newCredHeaderInjector:channel-key 是接入点配置(与base_url同类、成对配置),不是凭据机制,与auth_mode正交 —— 不属于 specauth-guidelines中「一个请求只携带一种凭据机制」所约束的对象。空值完全不注入该头(键不存在,而非注入空值):保证主站用户与独立域名渠道用户的线路字节零变化。这刻意区别于同文件
Cookie/Csrf-Token「空值也照旧 set」的存量契约 —— 那是必须保持的历史行为,而本头是新增的,注入空头会给全部存量用户构成回归。测试以「键不存在」断言。channel-key 归入「连接类参数」,早于远程校验应用:否则专属云 profile 会陷入「配置时校验即失败 → 配不上 → 永远配不上」的死锁。与既有 base-url 死锁保护注释同理。
验证
真实专属云账号 + 真实网关实测(每个矩阵行使用独立全新 HOME,杜绝配置残留):
config add一步建 profile 可用(其自身的 region/project 远程校验已带上该头并通过)Header.Set会将头名规范化为Channel-Key,实测网关照常接受(HTTP/1.1 与 HTTP/2 均验证)channel_key仅落config.json,不进credential.json已知局限(继承自
--base-url,非本次引入)os.Args扫描只识别--channel-key X空格形式,--channel-key=X静默失效。对照实验确认--base-url=X、--profile=X同样如此,属既有设计局限(该扫描需早于 cobra 解析运行),本次不修正以保持改动收敛。附记
实测发现 channel-key 与账号所属渠道不匹配时,网关同样返回 174,与 token 过期同码。既有的
authRetCodeWhitelist{174}会因此误触发一轮刷新+重放。已在client.go注释留档以备排障,本次不改控制流(改动会波及正常的过期刷新路径)。