|
|
cf53d72af4
|
fix: 回退两处内核改动，channels 改为插件自持持久化（照参考实现）
用户指出「你又tm改内核？」—— 核对后确认两处本可避免：
1. internal/lua/vm.go +32 行 新增 base64_decode 全局函数
2. internal/lua/plugin_http_handler.go +16 行 InvokeHandler 补 markDirty
工作区已还原到 v2.0.2（git diff v2.0.2 = 0 行）。
参考实现（dsh-our-free-model/vendor/channel-pack）对同一问题的做法：
- 解 JWT：用**语言自带**的 `Buffer.from(..., 'base64url')`，从不为此改宿主。
→ 我改成了插件的纯 Lua b64url_decode（约 20 行），实测解出真 JWT 的
nickname/sub/exp 全对。
- 状态持久化：插件**自己 writeFileSync+renameSync** 写
`channel-pack/state.json`，从不依赖宿主 settings。
→ 参考还记下了同构教训（Gitee IKI7WT）：DSH 0.1.7 移除 settings.register()
后账号列表退化为纯内存；正解是**插件探测宿主能力、自持文档**，不是要求
宿主改。我的 markDirty 修法方向相反：把插件的数据安全外包给宿主某条
分发路径的实现细节。
- `.channels-store.json`（tmp + rename 原子替换），只放**索引与配置**
（账号条目含 credentialRef 而非凭据本身、模型黑名单、设置、事件日志）。
凭据仍在 .secrets/（0600），两者分离：即便文档泄露也不含 token。
- 变更点同步落盘（不用「置标志+定时 flush」）：本插件无 hooks、45 个端点
各自变更状态，还有大量内部互调；挂在某个边界就必须保证**每条**路径都
经过它，漏一条就是「操作成功但重启丢失」——正是本次要修的缺陷形态。
状态实测 ~1.7KB，写入只发生在运维动作上，不在请求热路径。
- 黑名单写入收口到 setModelDisabled（写点曾有 5+ 处，散着写必漏）。
- 存量迁移：读内核遗留 `.channels.state.json`（v2.0.4 内核写的）→ 写自有
文档 → **写成功才删**遗留（写失败还删=用一次迁移丢数据）；自有存储已存在
时也删遗留，否则内核 restore() 会在启动时用它覆盖。
1. **测试污染生产目录**（严重）：插件 storeDir() 读 /etc/llmsproxy/config.yaml
决定落盘位置，而既有测试都没隔离 → 一次全量测试把 26 个测试账号写进了
**生产** .channels-store.json（含 fixture-a/example 等夹具 id）。
prod 文件已删除（真实账号另有来源）；kernelTestCore 现在隔离插件目录，
且尊重调用方已设的值（多次「重启」需共用同一目录）。
2. model_set_disabled 改了写入口后仍引用已删除的局部变量（nil 索引崩溃）。
- TestChannelsStoreIsPluginOwned：状态写进**插件自己的**文件、不含凭据字段、
新实例读回。变异（markDirty 空操作）→ FAIL。
- TestChannelsMigrationKeepsLegacyOnWriteFailure：**写失败必须保留遗留文件**。
变异（无条件删）→ FAIL。（这条单独测：迁移成功后的删除有两条路径互相掩盖，
只测「最终文件没了」区分不出「写失败也删了」。）
- TestChannelsMigratesLegacyKernelState：遗留账号迁入内存 + 自有存储写出 +
遗留文件删除。
- 内核对照 v2.0.2：diff 为空。
go test ./internal/core/（78s）与 ./internal/lua/（63s）全绿；
全量测试后确认生产插件目录未被写入。
|
2026-10-13 09:34:13 +08:00 |
|
|
|
893857464d
|
feat(channels): TRAE callback 真实移植 —— token 直传 + ExchangeToken（照参考逐行）
此前 oauth_callback 是通用 OAuth 形态（直接拿 code 当凭据），与 TRAE 真实
行为不符。参考实现 trae-oauth.ts 的回调是 **token 直传**，本次照其行为移植：
parseTraeCallbackDetailed（决策表 5 行）：
行1 refreshToken 直传（或 userJwt.RefreshToken 回退）→ ExchangeToken 换新
access（请求体 ClientID/RefreshToken/ClientSecret:'-'/UserID 照抄，
响应取 Token）→ 凭据 = 新 access
行2 无 refreshToken 但有 userJwt.Token → 直接兜底，**不打** ExchangeToken
行3 只有 code/authCodeInfo → PKCE 流，明确报"暂不支持"而非含糊失败
（参考注释强调：判为无效会让用户往错误方向排查）
行4 全空 → 报"回调未携带 refreshToken / userJwt.Token / code"
行5 ExchangeToken HTTP 失败 → 错误指明 ExchangeToken 阶段
配套：
- PLATFORMS.trae 增加 callback = {mode="trae", exchange_url, exchange_body}；
- oauth_callback 按平台 callback.mode 分派（nil→code 旧路径不变，googleish 不受影响）；
- traeCallback/jsonField 新函数；set_endpoints 支持 callback.exchange_url 覆盖
（既是运维能力也是测试缝，与 device 端点同语义）；
- TestTraeCallbackBehavior：5 行决策表 + 行1 断言凭据来自假上游新 Token
（防"把回调原值当凭据"）、行2 断言 ExchangeToken 零调用（防多余上游请求）。
回归：channels/trae/device 变异/压力/legacy/保险库/e2e 全绿。
|
2026-10-11 22:35:18 +08:00 |
|
