mirror of
https://gitcode.com/JianFeeeee/ModelRouter.git
synced 2026-11-07 09:47:23 +00:00
用户报障:「检查一下,同时修复坏渠道,还有插件不是可以自己决定注册 哪些渠道吗?你怎么不修一下,还有除了 billing 以外的两个插件都没有正确的 图标,而且另外两个插件计费也不正确」 ## 一、坏渠道(都在插件里修,不动内核) ### 1. zcode —— base_url 吞掉了 endpoint 路径(404) `base_url = https://zcode.z.ai/api/v1/zcode-plan/anthropic` `endpoint = /api/v1/zcode-plan/anthropic/v1/messages` 内核 URL = base_url + endpoint(provider.go ChatURL)⇒ 路径拼两遍: `.../anthropic/api/v1/zcode-plan/anthropic/v1/messages` → 404 page not found。 修:base_url 只留 host,完整路径进 endpoint。与 v2.0.30 「12 平台 base_url 侵占 endpoint」同族。 ### 2. minimax —— 打到 Web 前端(404「简单指令,无限可能」) base_url 只到 host + adapter=openai ⇒ 请求 /chat/completions,那是 Web 前端。 照参考 minimax-product.ts: MINIMAX_INFER_PATH = /mavis/api/v1/llm/v1/messages(**Anthropic Messages**) 实测(2026-10-19): /mavis/api/v1/llm/v1/messages → 401 invalid access token(路径对) 裸 /chat/completions → 404 page not found /mavis/api/v1/chat/completions → 404 修:endpoint 指向真实推理路径 + adapter 改 anthropic(第二层:协议形状)。 修后从 404 变 401(凭据问题,不再是路由问题)。 ### 3. codearts —— 只声明"可续期"却没声明"怎么续" `account_refresh` 走 `refreshCredential()`,要求 `plat.refresh.url` 或 `refresh_fn` 存在。codearts 只有 accountView 里硬编码的 `refreshable=true` ⇒ 恒返回「该平台未声明续期方式」,自动续期链空转,日志反复 `模型刷新失败 HTTP 400`。而 STS security_token 只有 1 小时寿命,过期后 每个请求都是 `APIG.0602: the security token has expired`。 修法(三层,每层都有独立的坑): a) 加 `refresh_fn` 钩子。华为云 STS 要 **DPoP 头**(jwk 在凭据里), 声明式 REFRESH_STYLES 拿不到私钥 ⇒ 必须用钩子挂已有的 `codeartsRequestToken`。 b) **JWK → PEM 重建**。`codeartsNewDpop()` 返回 {pem,public,private},但 凭据只持久化了 private(JWK),pem 是登录临时文件。而 `codeartsDpopSign` 走 openssl 命令行要 `key.pem` 字符串 ⇒ 直接传会报 `bad argument #1 to 'write' (string expected, got nil)`。 手工组 SEC1 `EC PRIVATE KEY` 的 DER(INTEGER 1 / OCTET STRING d / [0] OID prime256v1 / [1] BIT STRING 04||X||Y)再 PEM 包装。 c) 绑定放在**文件末尾的绑定循环**(与 claim_fn 同处)。在 PLATFORMS 表里 内联会闭包捕获当时的全局 nil —— 与 trae headers_fn 那次同一坑。 ## 二、插件图标(3 个坏 1 个) billing 有 SVG 但**缺 stroke/fill=currentColor**(深色主题下不可见); channels 声明 `icon = ""`(侧边栏空白);quota 连 icon 字段都没有。 统一成 inline SVG + `stroke="currentColor"`(照参考 src/sponsor.js:52 的 图标工厂形状)。 ## 三、判据(4 条,全部做过变异验证) - `TestChannelBaseURLDoesNotSwallowEndpoint`:base_url 里的路径段不得在 endpoint 重复出现。**走真实加载插件**而非正则读源码 —— PLATFORMS 是 Lua 表,有注释/条件拼装/末尾绑定循环,正则会给出假绿。 - `TestMinimaxUsesAnthropicProtocolAndRealInferPath`:路径 + 协议双断言。 - `TestCodeartsDeclaresRefreshHook`:分开报 has_refresh_fn / has_refresh_decl。 只看 refreshable 不够 —— 那是"凭据类型可续",与"平台实现了续期"是两件事。 - `TestCodeartsRebuildsPemFromJwkAndSigns`:**必须真签名**。DER 结构错、 长度错、base64 换行错都得到"非空但无效"的 PEM,只断言非空等于没验。 - `TestB64urlDecodeHandlesLongInput`:补一个真实测漏 —— 我的 b64urlDecode 第一版在输出字节后没清高位(缺 `buf = buf % (2^nbits)`),43 字符的 JWK 字段(32 字节)测出来**完全正确**,于是 PEM 判据在变异后依然全绿。 只有 86 字符的长输入才暴露(double 精度耗尽 → string.char 抛 invalid value)。 这条判据就是为"能跑、能返回、产物错"那类缺陷写的。 - `TestEveryPagePluginDeclaresSVGIcon` / `TestIconUsesCurrentColor`: 按**页面插件清单**遍历而不是只覆盖 billing。billing 当年空串的判据只管 它自己,于是 channels 空串、quota 缺字段时全绿 —— 同类缺陷换文件复发 没有任何东西会响。这条测试还当场咬出了 billing 自己缺 currentColor。 变异验证:zcode base_url 回退 ✓ / minimax adapter 回退 ✓ / 删 refresh_fn 绑定 ✓ / 去掉 buf 掩码 ✓ / OID 多套一层 TLV ✓(5/5 全部咬住) ## 四、计费(诊断,未改价) 查清"计费不正确"的根因:`prices.models` 只配了 **2 条** (deepseek-v4.1-flash + 它的 / 前缀形式),而实际在用 **193 个模型** ⇒ 112006 次请求里 **35672 次(31.8%)成本按 $0 计**。 其中 28203 次集中在 2026-10-05 一天(历史一次性事件); 当前每天 27~137 次,且**渠道模型全部未定价** (Doubao-Seed-2.1-Pro / GLM-5.3-Flash / MiniMax-* / qwen3.6-plus / hy3)。 调研:参考插件从 **models.dev** 拉模型目录(含 cost.input/output)。 实测 models.dev 覆盖我们 139/193 模型(72%),但**不能取中位数** —— 同一模型不同 provider 价差可达数千倍(glm-5.2 从 0 到 1.82), 0 价多是订阅制/coding plan。按 host 匹配 provider 只覆盖 6/24 源。 ⇒ 价格口径需要用户确认,本轮不动价表。 6 个新探针(仅测试/诊断用):__platform_def_probe(平台定义真相)、 __codearts_jwk_pem_probe(PEM 重建 + 真签名)、__b64_probe(解码字节)。
185 lines
6.7 KiB
Go
185 lines
6.7 KiB
Go
package core
|
||
|
||
import (
|
||
"encoding/base64"
|
||
"encoding/json"
|
||
"os"
|
||
"strings"
|
||
"testing"
|
||
)
|
||
|
||
// codearts JWK→PEM 重建判据。
|
||
//
|
||
// 背景(真实缺陷,2026-10-19 用户报「华为云源用不了」):
|
||
//
|
||
// 华为云 STS 的 security_token 只活 1 小时,续期(refresh_token 换新)需要
|
||
// DPoP 请求签名。签名走 `codeartsDpopSign(key, ...)`,它要求 `key.pem` 是
|
||
// **PEM 字符串**(内部用 openssl 命令行签)。而持久化的凭据里**只有**
|
||
// `dpop_private_key_jwk`(私钥的 JWK)—— PEM 是登录时的临时文件,没保存。
|
||
//
|
||
// 于是续期必须先从 JWK 重建 PEM。这条判据钉住"重建出来的 PEM 真能被 openssl
|
||
// 接受并签出有效的 ES256 JWS",而不是"函数返回了非空字符串"。
|
||
//
|
||
// 为什么必须真签名:DER 结构错、长度字段错、base64 换行错,都会得到
|
||
// **非空但无效**的 PEM。只断言非空等于什么都没验。
|
||
func TestCodeartsRebuildsPemFromJwkAndSigns(t *testing.T) {
|
||
// 一个结构合法的 P-256 私钥 JWK(生产凭据的真实形状:三个字段都是
|
||
// 32 字节 base64url)。用固定值而非随机生成,是为了让失败可复现。
|
||
jwk := map[string]any{
|
||
"crv": "P-256",
|
||
"kty": "EC",
|
||
"d": "BpkBLfUUij8IPn0Mzs6C64RfhQkF378yyQPeCR5sh7U",
|
||
"x": "r2HUYfG7tMIWY9KOpXLvvMWE_7dnHM9K7p1K7-LSwl4",
|
||
"y": "0-weI5p_EXZXFfGx4a76X_0oamkLOJ5AA4MOMObL8MM",
|
||
}
|
||
|
||
_, ps := poolCore(t)
|
||
out, err := ps.Call("channels", "__codearts_jwk_pem_probe", map[string]any{"jwk": jwk})
|
||
if err != nil {
|
||
t.Fatalf("探针调用失败: %v", err)
|
||
}
|
||
wrapped, _ := out.(map[string]any)
|
||
inner, _ := wrapped["json"].(map[string]any)
|
||
if inner == nil {
|
||
t.Fatalf("探针返回缺 json 包装: %#v", out)
|
||
}
|
||
if e, _ := inner["error"].(string); e != "" {
|
||
t.Fatalf("JWK→PEM 重建失败: %s", e)
|
||
}
|
||
|
||
// ① PEM 形状必须是 openssl 认的 SEC1 EC PRIVATE KEY
|
||
pem, _ := inner["pem"].(string)
|
||
if !strings.HasPrefix(pem, "-----BEGIN EC PRIVATE KEY-----") {
|
||
t.Fatalf("PEM 头部不对: %q", firstLine(pem))
|
||
}
|
||
if !strings.Contains(pem, "-----END EC PRIVATE KEY-----") {
|
||
t.Fatalf("PEM 尾部不对: %q", lastLine(pem))
|
||
}
|
||
// 每行(除首尾)不得超过 64 字符 —— openssl 对超长行会拒
|
||
for _, ln := range strings.Split(strings.TrimSpace(pem), "\n") {
|
||
if strings.HasPrefix(ln, "-----") {
|
||
continue
|
||
}
|
||
if len(ln) > 64 {
|
||
t.Fatalf("PEM base64 行长度 %d > 64,openssl 会拒绝", len(ln))
|
||
}
|
||
}
|
||
|
||
// ② 最关键:真签名必须成功(DER/长度/换行任一错都在这里暴露)
|
||
if ok, _ := inner["signed"].(bool); !ok {
|
||
t.Fatalf("PEM 重建后 DPoP 签名失败: %v", inner["sign_error"])
|
||
}
|
||
|
||
// ③ 签名产物必须是三段式 JWS(header.payload.signature)
|
||
// 探针不直接回 JWS,但 signed=true 已表示 codeartsDpopSign 走完了
|
||
// 整个 openssl 签名 + DER→raw 转换链路(任一环节失败都会返回 nil)。
|
||
}
|
||
|
||
func firstLine(s string) string {
|
||
if i := strings.IndexByte(s, '\n'); i >= 0 {
|
||
return s[:i]
|
||
}
|
||
return s
|
||
}
|
||
|
||
func lastLine(s string) string {
|
||
s = strings.TrimRight(s, "\n")
|
||
if i := strings.LastIndexByte(s, '\n'); i >= 0 {
|
||
return s[i+1:]
|
||
}
|
||
return s
|
||
}
|
||
|
||
// TestCodeartsKeyFromJwkRejectsBadJwk 钉住"坏 JWK 要响亮报错"。
|
||
//
|
||
// 为什么需要:JWK 字段长度不对(例如被截断、或根本不是 P-256)时,
|
||
// 若静默构造出一个畸形 PEM,openssl 只会说「签名失败」—— 运维无从判断
|
||
// 是凭据坏了还是代码坏了。必须在这里给可诊断的消息。
|
||
func TestCodeartsKeyFromJwkRejectsBadJwk(t *testing.T) {
|
||
cases := []struct {
|
||
name string
|
||
jwk map[string]any
|
||
}{
|
||
{"d 太短", map[string]any{
|
||
"kty": "EC", "crv": "P-256",
|
||
"d": "AAAA", "x": "r2HUYfG7tMIWY9KOpXLvvMWE_7dnHM9K7p1K7-LSwl4",
|
||
"y": "0-weI5p_EXZXFfGx4a76X_0oamkLOJ5AA4MOMObL8MM"}},
|
||
{"缺 x", map[string]any{
|
||
"kty": "EC", "crv": "P-256",
|
||
"d": "BpkBLfUUij8IPn0Mzs6C64RfhQkF378yyQPeCR5sh7U"}},
|
||
}
|
||
for _, c := range cases {
|
||
t.Run(c.name, func(t *testing.T) {
|
||
_, ps := poolCore(t)
|
||
out, err := ps.Call("channels", "__codearts_jwk_pem_probe", map[string]any{"jwk": c.jwk})
|
||
if err != nil {
|
||
return // 调用层报错也算响亮
|
||
}
|
||
wrapped, _ := out.(map[string]any)
|
||
inner, _ := wrapped["json"].(map[string]any)
|
||
if inner == nil {
|
||
return
|
||
}
|
||
if e, _ := inner["error"].(string); e == "" {
|
||
if ok, _ := inner["signed"].(bool); ok {
|
||
t.Fatalf("坏 JWK 竟然签出了名 —— 应当报错")
|
||
}
|
||
}
|
||
})
|
||
}
|
||
}
|
||
|
||
// 让 goimports/json 相关导入不被误判未使用(此文件仅用 json 做类型断言辅助)。
|
||
var _ = json.Marshal
|
||
var _ = os.Getenv
|
||
|
||
// TestB64urlDecodeHandlesLongInput 钉住 base64url 解码的**长输入**正确性。
|
||
//
|
||
// 这个判据补的是一个真实的测漏:我第一版的 b64urlDecode 在输出字节后
|
||
// **没有清除已用掉的高位**(缺 `buf = buf % (2^nbits)`)。用 43 字符的
|
||
// JWK 字段(32 字节)测时**结果完全正确** —— 于是那条 PEM 判据在变异后
|
||
// 依然全绿,什么也没验到。
|
||
//
|
||
// 只有长输入才暴露:累积缓冲不清高位时,double 精度在约 11 个 6bit 组后
|
||
// 耗尽,math.floor 给出越界值,string.char 直接抛 invalid value。
|
||
// 实测:把 `string.rep(43字符JWK, 10)` 喂进去,无掩码版本当场崩。
|
||
//
|
||
// 所以这里必须用**长串**(远超过 11 组),断言解出的字节数与内容都正确。
|
||
func TestB64urlDecodeHandlesLongInput(t *testing.T) {
|
||
// 96 个字符 → 72 字节。远超溢出临界点(11 组 = 66 bit)。
|
||
const in = "BpkBLfUUij8IPn0Mzs6C64RfhQkF378yyQPeCR5sh7UBpkBLfUUij8IPn0Mzs6C64RfhQkF378yyQPeCR5sh7U"
|
||
// 期望值由 Go 标准库算出(不用手写的 Lua 结果做锚,否则自证)
|
||
want := base64.RawURLEncoding.EncodeToString
|
||
|
||
_, ps := poolCore(t)
|
||
out, err := ps.Call("channels", "__b64_probe", map[string]any{"s": in})
|
||
if err != nil {
|
||
t.Fatalf("探针调用失败(很可能是 string.char 越界 = 缺高位掩码): %v", err)
|
||
}
|
||
wrapped, _ := out.(map[string]any)
|
||
inner, _ := wrapped["json"].(map[string]any)
|
||
if inner == nil {
|
||
t.Fatalf("探针返回缺 json 包装: %#v", out)
|
||
}
|
||
got, _ := inner["hex"].(string)
|
||
n, _ := inner["len"].(float64)
|
||
|
||
// 期望长度由 Go 自己算(不要手推 len/4*3:输入不一定是 4 的倍数)
|
||
dec, derr := base64.RawURLEncoding.DecodeString(in)
|
||
if derr != nil {
|
||
t.Fatal(derr)
|
||
}
|
||
if int(n) != len(dec) {
|
||
t.Fatalf("解码长度 = %v,期望 %d", n, len(dec))
|
||
}
|
||
// 与 Go 解码结果逐字节比对
|
||
wantHex := ""
|
||
for _, b := range dec {
|
||
wantHex += string("0123456789abcdef"[b>>4]) + string("0123456789abcdef"[b&0xf])
|
||
}
|
||
if got != wantHex {
|
||
t.Fatalf("解码内容不符(长输入下高位未清除):\n got=%s\nwant=%s", got, wantHex)
|
||
}
|
||
_ = want
|
||
}
|