|
|
de7553eaa2
|
feat(lua)!: 插件只通过 modelrouter SDK 与内核交互，且不再随内核安装
- 新增唯一公开接口表 `modelrouter`（sdk_version=1.0）：http / secrets /
kernel / adapters / plugin_dir。成员与内部桥是**同一对象**而非副本 ——
复制会让凭据保险库分叉（插件写 A、内核读 B）。
- `llmsproxy` 与 `__llmsproxy_*` 降为同对象兼容别名，只为已装插件继续可用。
仓库内 4 个插件（channels / billing / quota / usage）全部改用
`modelrouter.*`：此前它们直接依赖内核私有全局，内核无法在不炸插件的前提下
改实现（重命名、加守卫、换实现都算破坏性变更）。
- 插件不再由网关安装：`SeedBundled()` 变彻底 no-op，`core.New` 不再调用；
`ReadBundledPlugin` 改为按源文件定位（脱离 cwd），只服务测试与开发工具。
- 桌面端删除 `BUILTIN_PLUGINS` 与 `syncBundledPluginsOnUpgrade`：升级不再
删除、改名或覆盖用户插件文件。插件是运维资产，不是内核资源。
- `Builtin` 不再靠"源码与仓库示例逐字节相同"推断，插件一律视为外部文件。
- 判据：SDK 存在/版本/形状、别名与内部桥同一张表、适配器 VM 拿不到 SDK、
经 SDK 真实写读凭据并驱动内核动作、GUI 升级不动插件文件、release 包不含插件。
说明：channels.lua / quota.lua 同时带有此前的渠道与额度改动（含 OpenCode 免费池
监控），与 SDK 改名同处一个文件，无法文件级拆分，故一并纳入。
|
2026-10-26 22:27:12 +08:00 |
|
|
|
af8b93bd7c
|
fix(内核+插件): 测试写生产账号池 —— 13 个账号被覆盖成 0 个（真实数据事故）
用户报"完全不可用"。逐平台查 account/list，发现 13 个账号里只有 1 个有凭据，
其余是占位壳子 —— 再查发现**账号池被清空了**，而保险库里凭据还在
（症状正是"账号凭空消失"）。本提交修的是这个数据事故的根因。
## 根因（全程实测，非推断）
channels 插件用 `storeDir()` 决定自己的存储位置，它有多级兜底：
env → settings → **读 /etc/llmsproxy/config.yaml 的 plugin_dir** → 硬编码。
测试台没设 `LLMSPROXY_PLUGIN_DIR` 时，后两级直接命中**生产**：
测试插件目录 = /tmp/TestXXX/002/plugins
storeDir 结果 = /etc/llmsproxy/plugins ← 实测输出
于是测试加载真 channels.lua 时**读的是生产存储、写的也是生产存储**。
一次全量 `go test ./internal/lua` 就把
`/etc/llmsproxy/plugins/.channels-store.json` 从 1730 覆盖成 1986 字节、
账号池清空（inode 都换了）。
同类前科：曾把 26 个测试账号写进生产 store。两次同一类错误。
## 修法（两层，第二层才是根治）
1. **内核把插件的真实目录交给插件**（ground truth，不再靠猜）：
新增 `__llmsproxy_plugin_dir` 全局，在 bootPluginState 里注册。
`storeDir()` 优先用它 —— 这样**即使没有环境变量**也不会落到生产路径。
实测：撤掉 env 后 storeDir 仍落在临时目录。
2. 测试台补隔离：`runtimePlugins` 设 env + `DisableStatePersistence()`
（插件声明了 schedule 时内核会自动起调度器，**后台 goroutine** 比
`t.Setenv` 生命周期长，测试结束后仍可能落盘）。
## 判据 + 变异验证
`internal/lua/store_dir_isolation_test.go`：
- storeDir 绝不能是 /etc/llmsproxy 前缀
- 必须落在临时目录
- env 必须真的被设上（机制而非巧合）
**变异验证**：把隔离设成生产路径 → 判据变红并打印
「storeDir 指向了**生产**目录」；恢复 → 变绿。
全量回归：9 个包全绿，且 `go test ./...` 后生产存储**未被改动**（此前必被改）。
|
2026-10-14 11:31:41 +08:00 |
|
|
|
74ec1e7874
|
refactor(lua): 内核回归六项职责 —— 登录/浏览器全部移入插件
用户钉死了内核的职责边界，本提交把越界部分全部拆除：
内核只做：加载适配器 · auto 调度 · 加载插件 · 调度插件 · 维护源与 key · 签发密钥
## 架构纠正（用户指出的根本错误）
我此前把信任模型弄反了。实测：插件 VM 的 os.execute/io.popen/package 全部可达
(true,true,true) —— 插件从来不是 OS 级沙箱。正确的边界是：
插件 可信（运维安装），非沙箱，有完整 OS 能力 → 平台知识/登录/浏览器归它
适配器 不可信（可被动态安装），请求级 → 沙箱归它（12 个内置适配器实测均不碰
os/io/package，后续沙箱化零风险，属独立一步）
## 删除（内核越界部分）
- plugin_browser.go 内核浏览器管理器（Xvfb/chromium/x11vnc/websockify
进程栈、回环监听器）—— 388 行全删，浏览器由插件用
os.execute 自己拉起（实测 spawn+reap 闭环可用）
- plugin_login.go 登录会话状态机 + LoginFlow 枚举 + VNC 全局门禁
—— 457 行全删。"登录"从内核概念中消失
- gateway/browser_proxy.go viewer 反代
- handlePluginLogin API 登录会话列表端点
- vnc_enabled 全局开关 改为 per-plugin 授权（见下）
## 新增（内核职责内的通用机制，无任何登录/浏览器语义）
- plugin_outbound.go 通用额外出站主机授权：插件声明 plugin.hosts（请求）
→ 运维在设置页逐个批准（授权）。与 kernel actions
同一"声明≠授权"模型。内核只知道白名单加减，不知道
host 被用来干什么
- on_unload 生命周期钩子 卸载是"调度插件"的一部分：内核在关闭插件状态前调用
插件导出的 on_unload，让它自清理外部资源。内核不知道
资源是什么（进程/句柄/远端会话都行）。带进程回收回归
测试 TestOnUnloadReapsPluginProcesses
## channels.lua 全量接管
- 登录会话自持：plugin.state.sessions（nonce 只在 begin 响应出现一次，
惰性过期清理）
- 服务端浏览器栈自持：spawnBrowser 用 io.popen 拉起 Xvfb/chromium/x11vnc/
websockify 并记 pid，reapBrowser 回收；on_unload 兜底
- 优先级阶梯（用户指定）：① 本机浏览器（给 URL）→ ② 自动化（轮询/nonce 回调）
→ ③ VNC 无头浏览器兜底（无浏览器系统/自动化无法完成的场景，如回环重定向
必须落在服务端）
- plugin.auth_hosts → plugin.hosts（语义泛化：出站主机授权与登录无关）
## 验收
- 全仓旧符号零残留（grep 权威确认，代码+注释+lua+测试）
- 内核非测试代码零厂商名
- build + vet 全绿；lua/core/gateway/types/scheduler/provider 全量测试通过
- channels 端到端（登录→凭据→add_source→模型可见）继续通过
|
2026-10-11 16:24:55 +08:00 |
|
|
|
fa50ec8bc7
|
feat(lua): 服务端浏览器登录（VNC）+ 内嵌页签 —— 回环回调的唯一自动化路径
用户指明的场景修正了我的一个实质错误。我之前写"VNC 不解决取凭据，凭据还在
浏览器 profile 里"——这对 cookie 类成立，但对**回环重定向**不成立：
浏览器在用户机器 → redirect 到 127.0.0.1:P → 打到**用户的**回环 → 服务端收不到 code
浏览器在服务端 → redirect 到 127.0.0.1:P → 打到**服务端的**回环 → 插件直接收到 code
后者不需要"提取凭据"，code 自己流到监听方。所以对回环类登录，服务端浏览器
不是权宜之计而是**唯一自动化路径**。已实测验证（浏览器在服务端时 loopback
回调的 code 落到了服务端监听器）。
## 实现
plugin_browser.go：Xvfb(:N) ← chromium → x11vnc → websockify(noVNC) + 回环回调监听。
五个进程一起起停，因为失败模式是顺序相关的（崩掉的会话留下的 Xvfb 会让下一个
chromium 以看起来像浏览器 bug 的方式失败）。
**默认关闭，且不是"开了 VNC 就能登全部"**：每个平台单独走 vnc 流程才启动。
理由是这套东西风险最高——在服务端跑真实浏览器登录用户的第三方账号。
**边界**：插件拿到的是 view_url，**不是浏览器控制句柄**。CDP 端口不进 Lua。
否则一个插件就能读所有标签页的 cookie，而那个浏览器登录的是运维的账号。
**teardown 必须删 profile**：里面是活的第三方 session cookie，删它是安全契约
的一部分，不是收尾工作。
## viewer 反代（browser_proxy.go）
/browser/<id>/... → 该会话的 websockify。为什么不直连端口：
1. 鉴权——直连等于把已登录的浏览器暴露给任何能访问该端口的人（实测未鉴权
访问得 302 → /login，带 admin key 得 3912 字节 noVNC 页面）
2. WebSocket——noVNC 核心是 WS 升级，httputil.ReverseProxy 原生处理
3. 同源——WS 路径不需要跨域配置
## 内嵌在插件页签（用户要求）
viewer 用 iframe 内嵌进 channels 插件的登录区，而不是让人跳出去开新窗口：
- 插件 UI 拿到 view_url 就塞进 iframe src，登录完成/失效时清空 src 并隐藏
- 插件只对 `flow = "vnc"` 的平台起浏览器；其他流程继续用用户自己的浏览器
（等于白开一个高风险的浏览器是浪费）
## 插件本体：channels（同类插件）
单插件多平台，4 个平台示范四种流程（link-poll / callback / paste / vnc）。
登录 → 凭据进保险库（不进 state）→ add_source 接入内核 → 定时领额度。
声明式：plugin.kernel 申请内核动作、plugin.auth_hosts 申请登录主机，
设置页显示"申请中"由运维批准。平台表加一条就多一个平台，内核零改动。
开发中被测试抓到的三个真实缺陷（都在我自己的代码里）：
1. handler 返回 `{url=…}` 没有 status/json → 内核**静默丢弃**，200 空响应、
无任何错误。已把所有 handler 统一为 {status,json}，并加契约测试锁死。
2. 插件把 req.body 当表用 → 实际是 JSON **字符串**，所有平台参数都读不到。
加 bodyOf() 统一解码。
3. 顺带发现工作树里 discover.go 被改成 `return "image"`（非本次改动，像是早先
变异测试留下的），会改变模型类型推断；已还原。
测试：服务端浏览器会话（进程栈/默认拒绝/回调捕获/teardown 清理 profile）、
viewer 反代鉴权、插件 VNC 端到端、channels 插件端到端（含未授权时如实报告
source_error 而非假装成功）、handler 契约。
|
2026-10-11 14:26:28 +08:00 |
|
|
|
c3b858d5ba
|
feat(lua): 多流程登录会话抽象（R4-e）+ 内核权限设置页
用户决策：**多流程抽象**（VNC 作逃生舱）+ **单插件多平台**。
## 为什么不是 VNC 为主路径（实测参考插件后的结论）
grep 参考插件（dsh-our-free-model，13 个账号渠道）的源码：
puppeteer / playwright / chromium / headless / vnc / selenium → 0 处
它的登录全部是**把 URL 交给用户自己的浏览器**，插件轮询凭据是否就绪：
loginUrl 113 次 · cookie 133 次 · oauth 43 次 · deviceCode 8 次 · qrcode 7 次。
不以 VNC 为主路径的四条具体理由：
1. Passkey/WebAuthn 基本不可用：凭据绑在用户设备，VNC 里是另一台机器。
2. 无头浏览器更容易被判为机器人 —— 登录场景最不能踩这个。
3. 安全面：llmsproxy 以 root 运行（master.key 0600），systemd 已 ProtectHome=yes。
从 root 服务开 VNC 通道到"即将登录用户各平台账号"的浏览器 = 提权面绑高价值目标。
4. 最关键：VNC 不解决取凭据。登录后凭据活在浏览器 profile 的 cookie 里，
还是要提取 profile —— 那正是最脆弱的一环。轮询流程直接产出 token。
VNC 唯一不可替代的场景（服务端与用户不同网 + 平台要求登录 IP 与调用 IP 一致）
使它作为逃生舱存在：**默认关闭**，需运维显式开启。
## 登录会话抽象（plugin_login.go）
四种流程：link-poll（首选）· callback（复用 Phase 6 自定义挂载）· paste（兜住
cookie 类渠道）· vnc（逃生舱）。内核只管会话生命周期，不含任何平台知识。
- 会话只存**状态**不存凭据：凭据由插件写进自己的保险库，会话里放一个
UI 可见的记录会让 token 有机会被列表接口带出去
- nonce 只在 begin 时给（后续读取剥离），空 nonce 不匹配任何会话
- 读取时判定过期，无后台定时器（没有登录请求时零开销）
- 跨插件读不可行，且与"不存在"不可区分（否则会确认 id 存在）
## 关键阻碍与修法：登录主机不在出站白名单里
**实测确认**：`auth.huaweicloud.com` 被白名单拒绝
（"not an allowed outbound destination (allowed: the hosts of configured sources)"），
整个登录流程无法工作 —— 因为登录主机不是上游源。
修法与内核权限同一姿态：插件在源码 `plugin.auth_hosts` **声明**，运维在设置页
**批准**后才放行。只能批准插件声明过的 host（否则声明只是装饰），逐个批准
不连带（否则一个"登录"理由就能打开整张名单）。
## 设置页
插件表格新增"内核动作"列 + 点击展开的权限面板：动作清单按危险级排序、勾选即
授权、**申请中但未授权会标红**（那通常意味着插件某功能静默失效）。
另加登录主机批准面板（已批准/待批准）。
后端 /api/plugins/{name}/kernel（GET 看 declared vs granted，PUT 改）
与 /api/plugins/{name}/login（列在飞会话，供页面显示"等待你完成登录"+ URL）。
开发中自己引入并修掉一个缺陷：renderPlugins → refreshKernelSummary →
renderPlugins 无限递归；改为只原地 patch 受影响的单元格。
测试 8 个：会话生命周期/跨插件隔离/callback nonce/登录主机门控/只能批准已声明/
过期判定/VNC 需显式开启/未知流程名被拒。node --check 验证内联 JS 可解析。
|
2026-10-11 13:56:35 +08:00 |
|
|
|
a59295e826
|
feat(lua): 插件可调内核动作面（R4-c）+ 凭据保险库（R4-d）
用户指出「接口不全」——此前插件只有 __llmsproxy_adapters 三个手写闭包，
够不到内核。对照参考插件（dsh-our-free-model，13 个账号渠道）的真实能力，
缺的正是这两块：
插件自己驱动链接认证 → 存凭据 → 定时领额度 → 把源接进内核
## R4-c 内核动作面：__llmsproxy_kernel
18 个动作，全部映射到既有 Core 方法（不是新造能力）：
只读 6：status / list_sources / list_models / list_adapters /
list_auto_rules / adapter_owner
写 8：reload / reset_health / probe_all / save_auto_rules /
save_key_auto / add_source / create_key / update_key
破坏性 4：remove_source / delete_key / remove_adapter / set_plugin_enabled
**add_source 是「插件注册自己的上游」的落点**——插件拿到凭据后可以自己把
端点接进网关，无需运维改 config.yaml。已端到端验证：插件调它 → 内核源列表
出现 → 模型进入可路由列表。
依赖方向：lua 不能 import core，所以接口定义在 lua、实现放 core
（kernel_actions.go），走 SetKernelAPI 注入——与 SetOutboundHosts 同一先例。
**凭据边界**：动作面**有意排除** list_keys/find_key。Core.ListKeys() 返回
明文网关密钥，交给第三方 Lua 等于交出整个部署的凭据面。有回归测试锁死
这条（TestKernelActionSurfaceExcludesPlaintextKeys）。list_sources 返回的
api_key 也强制掩码（只给 ***+后4位）。
**权限**（用户选「全开+设置页可配」）：18 个动作全部可达，但**默认拒绝**，
授权落盘 .kernel-perms.json（独立文件，不并进 .access.json——后者是
map[string]string，塞进去会破坏旧二进制能读的格式）。danger 级不接受通配符。
插件可在源码 plugin.kernel={...} **申请**，设置页显示申请 vs 已授予。
**Go 侧 deadline**（用户选定）：每个动作有超时预算，超时把 (nil,err) 还给
Lua。这可行的原因：Lua 只是等返回值，不占 Lua 栈执行权——与「Lua 死循环
不可中断」是两件事。
## R4-d 凭据保险库：__llmsproxy_secrets
此前插件存 token 只能写 plugin.state：0755 目录、明文、与计费累计量同文件、
会被 PUT /state 整体替换、会进 WebUI。现在独立文件：
<plugin_dir>/.secrets/<plugin>.json 文件 0600，目录 0700
临时文件**先 chmod 再 rename**，全程不存在宽权限窗口。读取身份在插件 boot
时绑定（不从 Lua 状态现读）⇒ 跨插件读不可行是机制而非约定。插件删除时清空
（DeleteAllSecrets + 启动 PurgeOrphanVaults）。
## 开发中被测试抓出的两个真实缺陷（我自己引入的）
写了 TestNoKernelActionDeadlocksFromLua 对**每个**动作断言「在插件 Lua 调用
（此时持有 p.mu）内不得死锁」，抓出：
1. **自死锁**：set_plugin_enabled → SetEnabled → p.mu.Lock()，而死锁发生在
调用者已持有的同一把锁上。
2. **更隐蔽的迟到副作用**：超时把 error 返回给插件后，动作仍在幕后执行完成——
插件以为失败，实际已生效。
修法：标注 Deferred 的动作在本次调用返回后异步执行，如实返回 accepted:true
而不是谎报成功。18 个动作全部复验无死锁，另有单独测试确认副作用真的落地
（只测「不死锁」的话，一个全空转的 dispatch 也能通过）。
测试 11 个（core 8 + lua 3）：动作可用/密钥掩码/默认拒绝/授权计数/
插件注册源并变为可路由/授权落盘重启保留/未知动作名被拒/凭据面排除明文/
全动作无死锁/破坏性动作生效/Lua 侧桥接可用。
|
2026-10-11 13:52:29 +08:00 |
|
