Skip to content

feat(platform): support channel-key header for dedicated cloud channels#141

Merged
Ali1213 merged 1 commit into
masterfrom
feat/channel-key-header
Jul 17, 2026
Merged

feat(platform): support channel-key header for dedicated cloud channels#141
Ali1213 merged 1 commit into
masterfrom
feat/channel-key-header

Conversation

@Episkey-G

Copy link
Copy Markdown
Collaborator

背景

专属云渠道用户(复用主站 API 域名的渠道)调用 API 报校验错误。网关需要 channel-key 请求头来定位「去哪个渠道的用户库查验凭据」,缺失时:

  • AK/SK 模式RetCode 171 Signature VerifyAC Error(即用户报障的「校验错误」)
  • OAuth 模式RetCode 174 Token Not Exists

CLI 此前没有任何 channel 概念(全库无相关实现),故这类用户无法使用 CLI 做日常操作。

改动

新增 profile 级可选配置 channel_key(落 config.jsonomitempty),在 attachHandlersWithManager 这一唯一汇聚点注入,因而覆盖全部 client 构造路径:products 的 cli.NewServiceClientapi 命令、config 子命令的远程校验、以及 AttachHandlers

文件 改动
config.go channel_key 配置项、全局 flag 字段、mergeConfigIns 覆盖、--config 新增 ChannelKey 列
client.go newChannelHeaderInjector + 挂载
root.go --channel-key 全局 flag(os.Args 扫描 + 注册)
configure.go config / config add / config update 三处入口,与 base-url 对齐

核心逻辑 77 行,其余为测试。

关键设计

独立 handler,不并入 newCredHeaderInjector:channel-key 是接入点配置(与 base_url 同类、成对配置),不是凭据机制,与 auth_mode 正交 —— 不属于 spec auth-guidelines 中「一个请求只携带一种凭据机制」所约束的对象。

空值完全不注入该头(键不存在,而非注入空值):保证主站用户与独立域名渠道用户的线路字节零变化。这刻意区别于同文件 Cookie/Csrf-Token「空值也照旧 set」的存量契约 —— 那是必须保持的历史行为,而本头是新增的,注入空头会给全部存量用户构成回归。测试以「键不存在」断言。

channel-key 归入「连接类参数」,早于远程校验应用:否则专属云 profile 会陷入「配置时校验即失败 → 配不上 → 永远配不上」的死锁。与既有 base-url 死锁保护注释同理。

验证

真实专属云账号 + 真实网关实测(每个矩阵行使用独立全新 HOME,杜绝配置残留):

场景 不带 channel-key 带 channel-key
AK/SK + 专属云域名 ❌ 171 Signature VerifyAC Error ✅ 成功
OAuth + 专属云域名 ❌ 174 Token Not Exists ✅ 成功
  • config add 一步建 profile 可用(其自身的 region/project 远程校验已带上该头并通过)
  • Go 的 Header.Set 会将头名规范化为 Channel-Key,实测网关照常接受(HTTP/1.1 与 HTTP/2 均验证)
  • 多 profile 隔离:未配置该项的 profile 不受影响
  • channel_key 仅落 config.json,不进 credential.json
  • 全量测试 14 包全绿;命令树 golden 仅新增 3 行 flag,无其他变化

已知局限(继承自 --base-url,非本次引入)

os.Args 扫描只识别 --channel-key X 空格形式,--channel-key=X 静默失效。对照实验确认 --base-url=X--profile=X 同样如此,属既有设计局限(该扫描需早于 cobra 解析运行),本次不修正以保持改动收敛。

附记

实测发现 channel-key 与账号所属渠道不匹配时,网关同样返回 174,与 token 过期同码。既有的 authRetCodeWhitelist{174} 会因此误触发一轮刷新+重放。已在 client.go 注释留档以备排障,本次不改控制流(改动会波及正常的过期刷新路径)。

专属云渠道用户(复用主站域名,如 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 注释留档,本次不改
控制流。
@github-actions

Copy link
Copy Markdown

🔴 平台 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
Ali1213 enabled auto-merge July 17, 2026 05:57
@Ali1213
Ali1213 disabled auto-merge July 17, 2026 05:59
@Ali1213
Ali1213 merged commit 62b2d4d into master Jul 17, 2026
12 of 13 checks passed
@Episkey-G
Episkey-G deleted the feat/channel-key-header branch July 17, 2026 09:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants