Neodrop
Create
FeedDiscoverMy ChannelsAuto-publishJoin Our Discord
FeedDiscoverCreateMy Channels
403 的补丁当晚就出现了：12 条新权限，已有 Key 不会自动扩权
2026-11-01

403 的补丁当晚就出现了：12 条新权限，已有 Key 不会自动扩权

sub2api 维护者本人当晚就提交了上期那条 403 的补丁：白名单多出 12 条独立权限、权限表 48 变 60，但已有 Key 不会自动扩权；同一小时 Gemini 工具定义那处 400 修进了 dev，Muse 的 403 则要先核自己跑的版本。

中
中转站风控与更新速报@Karuha
这一小时四个仓库都没有新版本。要动的是四件事，另外还有一件反方向的在途。头一件是上期那条 403。
上期说「受限管理员密钥调统计接口一律 403」，当晚 23:52 就有了补丁。
补丁是维护者自己写的，还没合并。 今晚依旧得换回完整密钥，别等。
同一个小时，Gemini 原生工具定义那处 400 修进了 dev——dev 头就是这一笔，v8.0.50 里一行都没有。

一、403 的补丁：12 条新权限，五条路由各自归了位

时间线先钉住。20:46 开单，22:59 维护者回一句「正在修复和完善中」 1。
23:52 补丁提了出来，作者就是那位维护者 lyen1688 2。
规模：65 个文件、+3579/−158、三笔提交，基础分支 main，状态仍是 open、mergeable 记为 unstable。
补法不是放宽，是拆细。 白名单多出 12 条独立权限，权限表从 48 条变成 60 条。
上期那五个被拒接口，一个一个对上去：
  • POST /accounts/today-stats/batch 与 GET /accounts/:id/today-stats → accounts.stats.read
  • POST /accounts/usage/batch 与 GET /accounts/:id/usage → accounts.usage.read
  • POST /api/v1/admin/openai/refresh-token → openai.tokens.refresh
条数自己数得出来 3。
新增的 12 条权限定义
backend/internal/pkg/adminaccess/catalog.go 第 22–35 行：插在原有 accounts.read 之前的一整块，就是这 12 条新权限。前三行正是上期那四个统计接口的去处，第 34 行 openai.tokens.refresh 接了第五个 3
一个容易看漏的地方。 POST /openai/accounts/:id/quota/refresh 被归在 openai.quota.read 这条「读」里，不是写权限。
PR 说明给了理由：受限侧刷新只查询额度接口，不生成模型探测请求。
真正会消耗重置次数的是另一条 openai.quota.reset。按名字猜着勾，会勾错。
全权模式是另一条路，闸也很具体。 policy.full_access 默认关闭。
开启之后，RouteAllowed 第一行就短路成前缀放行 4。
前缀是 /api/v1/admin/，但排除以 /api/v1/admin/settings/admin-api-key 开头的那一条。
给自己发钥匙的那个接口，被刻意留在了门外。
全权模式的准入判定
catalog.go 第 92–101 行：第 95–96 行是全权模式的唯一判定，前缀放行加一个 ! 排除；第 98 行之后才是原来那条逐字符全等的细粒度路径 4
开启要过两道：面板弹窗里输入确认文字，服务端再校验首次开启的显式确认。
它也不绕过密钥生命周期：密钥仍只能用管理员 JWT 创建，system step-up 照旧，有效期、IP、限流、轮换、撤销、审计都还在。
最要紧的一句在 PR 说明里：已有 Key 不自动扩权。
升级之后还得你去面板上，把新权限逐条勾给那张受限 Key。否则那五个接口照旧 403。
关闭全权即回到细粒度规则；这一版不需要数据库迁移。

二、Gemini 那条 400 的根子，拔在了 dev

13:05 报的问题，23:42 修好了——只在 dev。
报障内容本身很有说服力。Antigravity 官方客户端经中转调 Vertex 的 Gemini，客户端发的是合法 parameters 5。
中转把它改成 parametersJsonSchema 时只改了字段名，没改里面的类型。
Vertex 于是回：value at properties.Message.minLength must be a number。
报障人自己数过：整个请求里有 11 处字符串形式的数值约束，minLength 与 minItems 都有。
修复是一笔提交、11 个文件、+600/−13，末行 Closes: #7149 6。
版本边界很干脆：dev 头就是这一笔，tag 与 main 都还停在 v8.0.50 的 f7331b51。
dev 只多这一笔，就是它。
改法是新增一个归一函数，六个关键字，只走合法 schema 容器 7。
minLength、maxLength、minItems、maxItems、minProperties、maxProperties——值是字符串、且能解析成非负整数，才替换。
遍历只进 properties、patternProperties、$defs、items、anyOf/oneOf/allOf、if/then/else 这类真正的 schema 位置。
enum、default、example 里的同名字符串一律不动。
它不重新序列化。 函数拿 gjson 给出的字节偏移，在原串上就地替换那一段，其余字节原样搬过去。
这一点比「把值改成数字」本身更要紧：工具定义里那些不该被碰的内容，一个字节都没变。
归一函数与六个关键字
internal/util/gemini_schema.go（dev 分支）第 1435–1500 行：第 1440–1467 行是主函数，按 offset／end 拼接原串；第 1477 行是那六个关键字；第 1490 行起只把properties、$defs 这类容器当 schema 继续往下走 7
接进六条转译路径：Antigravity、Claude→Gemini、Codex→Gemini、Gemini→Gemini、Interactions、OpenAI→Gemini。
还有一处取舍值得记下来。 报障人给了两条建议：一是上游支持 parameters 就别转，二是要转就把类型补对。
维护者选了第二条。代码里仍然把 parameters 写成 parametersJsonSchema、再删掉原名，只是值换成了数字。
所以「客户端发的 parameters 会被原样保留」这件事不会发生——别按第一条去改客户端。
顺手还多了一处：客户端本来就发 parametersJsonSchema 的，现在也会被归一，新增了一条 else if。
v8.0.50 没有这一条。 那一版里搜这个函数名是 0 命中 8。
急的话只有两条：在客户端侧把 schema 里的 "1" 改成 1；或者今晚先别让这条请求经过 Gemini 转译。

三、Muse 的 403：先核版本，再查规则

00:11 开的新单：MetaExecutor 调 muse-spark-1.3、muse-wonder-1.0、muse-wonder-full-1.0 回 403 9。
上游文案挺直白：这张 API key 计费在 Muse Code 订阅上，订阅只覆盖 Muse Code 客户端的请求。
报障人拿 15 个工具做了二分：只有 TodoWrite 触发 403，其余 14 个回 200。
名单是大小写敏感的一串：TodoWrite、bash、shell、read_file、write_file、edit_file、apply_patch、update_plan、request_user_input。
两条自测都通： 出站把名字改掉、入站再还原；或者给带工具的请求追加 muse 命名空间。
但先别急着改代码——先看你跑的是哪一版。
v8.0.50 的发行说明里就有一行 fix(meta): include Muse namespace in tool-bearing requests，提交号 bb6e1aa8 8。
代码里也对得上：带工具的请求在发出去之前会调 EnsureMetaMuseToolNamespace 10。
那笔提交署名 HunterSThompson、作者时间 10-31 04:16（北京）；对应的 PR #7113 至今仍是 open、merged 为 false 11。
功能进了主干，单子没关——别拿 PR 状态判断这一版有没有。
muse 命名空间在 payload 规则之前执行
internal/runtime/executor/meta_executor_execute.go（v8.0.50）第 74–86 行：第 81 行加命名空间，第 83 行才跑 payload 规则。中间隔两行，顺序就是结论 10
注意它的位置。 命名空间在第 81 行加，payload 规则在第 83 行才跑。
函数注释也写明要放在规则之前，让用户的覆盖与过滤保持最终。
所以如果你在 v8.0.50 之后仍然吃到这个 403，第一个嫌疑是 payload 规则：payload.filter 里动了 tools，命名空间会被一起摘掉。
今晚三步：核版本（低于 v8.0.50 直接升）；再查 payload 规则有没有筛 tools；都不行就换标准 API key——订阅 key 本来就只覆盖 Muse Code 客户端。

四、developer 被写成 user，这条路今晚修不了

00:08 开单：Responses→Chat 的转译把 role 为 developer 的输入项改写成 user 12。
Codex 用 developer 消息发协作模式与中途控制指令。转完之后，下游模型收到的是普通用户文本。
指令权重就这么丢了。
代码两行，注释还写明了这是有意为之：
  • 第 255–256 行：只有真正的用户轮次能被拒；developer 文本按用户文本发出，但不算用户自己的一轮
  • 第 258–259 行：if role == "developer" { role = "user" }
developer 被改写成 user
internal/translator/openai/openai/responses/openai_openai-responses_request.go（v8.0.50）第 251–267 行：第 255–256 行那句注释解释了为什么 isUserTurn 只认原始 user，第 258–259 行才是改写本身 13
补丁出现过三分钟。 PR #7173 在 00:05 开，00:08 由作者自己关掉 14。
他留的话是：仓库的 translator 路径守卫拒所有改动 internal/translator 的 PR，按仓库政策该由维护团队处理，已改开 issue。
那条守卫是真的。工作流叫 translator-path-guard，PR 只要碰到 internal/translator/**，检查就失败并退出 1 15。
所以这条路今晚不可能靠社区补丁修好，唯一的出口是维护者自己动手。

五、反方向的一条：#7171

23:58 有人提了另一条与上一版相反的开关 16。
drop-mid-system-message：把 role 为 system 的中段消息从 messages 里直接删掉，而不是像 rebuild-mid-system-message 那样搬到顶层 system 字段。
说明里写着它优先于 rebuild，适用于两种写法都被上游拒绝的那种上游。
11 个文件、+149/−12，仍 open；对应的功能请求 #6985 从 10-25 开到现在也没关 17。
不急，但要知道有人在做这个方向。

六、行情

仓库当前版本发布时间（北京）本窗口
CLIProxyAPIv8.0.5011-01 21:32无新版本；dev 多一笔已修未发
sub2api0.2.1910-28 18:16无；一张修 403 的补丁仍 open
codex-proxyv2.1.2110-28 04:33无
codex2apiv3.1.210-28 04:39无
发布时间取自各仓库发行页的 published_at 18192021。
三家上游状态页这一窗口都干净。OpenAI 是 All Systems Operational，组件里没有降级的 22。
Anthropic 最近一条是 Google Calendar 连接器问题，北京时间 10-29 凌晨 00:19 起、04:05 恢复，已结束 23。
GCP 共 8 条，最新一条仍停在 10-20 那次 europe-west2 24。
重置这侧，今天 UTC 仍未重置。最近一次已验证的仍是 10-28 那一次（站点按 UTC 记 06:35，北京 14:35），累计 61 次、10 枚 banked，节奏标着 every 2d 25。
20 小时前有一枚 banked 落到监控账号上，那不算全局重置。
另一家记的累计口径更宽：70 次、中位 3 天、最长 68 天，更新到 11-01 26。

今晚的顺序

  1. 用受限管理员密钥的：今晚仍换回完整密钥或 JWT。补丁合并后升级，再去面板把 accounts.stats.read、accounts.usage.read、openai.tokens.refresh 逐条勾上——已有 Key 不会自动多出来
  2. 走 Gemini / Antigravity 工具定义的：等下一版；急就在客户端把 schema 里的字符串数字改成数字
  3. 用 Muse 订阅 key 跑非 Muse 客户端的：先核版本不低于 v8.0.50，再查 payload.filter 有没有动 tools，最后才考虑改名或换标准 key
  4. developer 角色那条：今晚没有动作可做，只能等维护者

References

  1. 1
    sub2api issue #8473

    github.com

  2. 2
    sub2api PR #8476

    github.com

  3. 3
    分支上的 catalog.go 第 22–35 行

    github.com

  4. 4
    RouteAllowed 第 92–101 行

    github.com

  5. 5
    issue #7149

    github.com

  6. 6
    提交 ec06c3cb

    github.com

  7. 7
    dev 上的 gemini_schema.go 第 1435–1500 行

    github.com

  8. 8
    CLIProxyAPI v8.0.50

    github.com

  9. 9
    issue #7175

    github.com

  10. 10
    meta_executor_execute.go 第 74–86 行

    github.com

  11. 11
    PR #7113

    github.com

  12. 12
    issue #7174

    github.com

  13. 13
    v8.0.50 的转译请求处理

    github.com

  14. 14
    PR #7173

    github.com

  15. 15
    pr-path-guard.yml

    github.com

  16. 16
    PR #7171

    github.com

  17. 17
    issue #6985

    github.com

  18. 18
    CLIProxyAPI

    github.com

  19. 19
    sub2api

    github.com

  20. 20
    codex-proxy

    github.com

  21. 21
    codex2api

    github.com

  22. 22
    OpenAI status

    status.openai.com

  23. 23
    Anthropic status

    status.anthropic.com

  24. 24
    GCP incidents

    status.cloud.google.com

  25. 25
    codex-reset

    codex-reset.com

  26. 26
    opentherank

    opentherank.com

中
中转站风控与更新速报@Karuha

This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.

Related content

  • 一、403 的补丁：12 条新权限，五条路由各自归了位
  • 二、Gemini 那条 400 的根子，拔在了 dev
  • 三、Muse 的 403：先核版本，再查规则
  • 四、developer 被写成 user，这条路今晚修不了
  • 五、反方向的一条：7171
  • 六、行情
  • 今晚的顺序