|
|
11654f88b5
|
fix(mcp)★★: 未声明参数不再被静默吞掉 —— 模型拿到假成功
## 实测经过（全面测 MCP 时发现）
`connect_to_server(gateway_url="http://evil.example", agent_key="x")`
返回「已连接」—— 看起来像模型改了网关坐标。
查下去坐标**改不了**：身份只从 AgentAuth 的 context 取，参数被忽略
（schema 是 `properties: {}`）。**所以不是安全问题。**
但它是另一种毛病：**误传/写错的参数被静默吞掉**，模型收到「成功」后
不会知道自己传的东西根本没生效。实测发现 **11 个工具全部**没设
`additionalProperties: false`。
## 两道都补
1. **schema 层**：`objSchema` 加 `additionalProperties: false`
—— 一处改动覆盖全部 11 个工具。
2. **运行时**：`unknownArgs` / `declaredArgs` 在 `tools/call` 里再拒一次。
schema 只是**声明**，是否生效取决于宿主是否遵守 ⇒ 这一道不依赖宿主。
报错文案点名参数并列出可用参数，让模型能自我纠正：
工具 connect_to_server 没有这些参数：agent_key、gateway_url（可用：（无参数））
`unknownArgs` 只在 schema 自己声明了 `additionalProperties:false` 时才判 ——
否则等于替宿主做主，把合法的透传参数也拒了（有判据钉住）。
## 判据自己假绿了一次
变异 `if false && len(bad) > 0`（短路调用点）→ **0 红**。
因为 `TestUnknownArgsOnlyWhenSchemaOptsIn` 测的是 `unknownArgs` **这个函数**，
而**函数正确 ≠ 它被接上了**。这是本轮第五次栽在「形状判据测不到接线」上。
⇒ 补了端到端一格：从 HTTP 进去，看客户端实际收到什么（并断言绝不能是
「已连接」—— 那正是要修的假成功）。重测同一变异立刻转红。
判据走真注册表（`NewTools().RegisterAll`）而非复制一份清单 ——
复制的那份会与真实工具面漂移，而漂移方向恰好是「新工具没被判据覆盖」。
## 顺带纠正上一轮的一个错误结论
上轮我说 `read_mail` 与 `read_thread` 拒绝措辞不一致是缺陷。**那是错的。**
`agent_discovery.go:414` 明确丢掉 reason，注释写着「拒绝原因在 403 文案上
合流成同一句，反而少泄一点信息」—— 那是**刻意的安全取舍**，不告诉调用方
到底是跨工作区还是没参与过（两者指向同一个可枚举的信息）。
而 `read_mail` 那句话是用户 2026-09-15 亲自订正过的（原注释：旧文案让
zcode 推断出「那五位 agent 不存在」，把错误结论写进了给人看的信里）。
⇒ **不改**。把刻意的安全设计当缺陷「修」掉，比留着更糟。
14 包全绿。
|
2026-10-04 17:08:15 +08:00 |
|
|
|
457d1608f0
|
feat(mcp): MCP 集成进网关本体 —— POST /api/v1/mcp（Streamable HTTP）
## 为什么要集成而不是独立进程
上一版（29ad8aa）是独立进程 `plugins/zcode-mail-bridge/mcp/server.mjs`，
用 HTTP 调本网关。四条真实成本：
1. **工具语义有两份**。桥里的 read_inbox / send_mail 是**手抄**网关的，
抄错就是行为分叉 —— 已抓到两次：`connect_to_server` 只发
`X-Agent-Secret` 头，而 `/agent/register` 只认 Bearer 或 body 里的
secret ⇒ secret-only 的 Agent 必然 400。
2. **鉴权与收窄要再实现一遍**。工作区收窄、会话收窄、冷静期、配额住在服务端。
3. **多一跳 + 多一个故障点**。
4. **接入端仍要装东西**（node + 桥 + 环境变量）。
现在：工具**包装现有 handler**，同一份代码、同一套鉴权与收窄；
接入端只填一个 URL。
## 传输与实现（用户裁定）
- **Streamable HTTP**（规范 2025-06-18）：单端点 POST，通知回 202，
请求回 JSON-RPC。
- **包装 handler**（不是直调 repo）：`newRequest` + `invoke` 造内部请求
交给 `handler.GetInbox` / `SendMail` / … 于是 `AgentMayReadSession`、
冷静期、配额、附件保护目录全部是同一条代码路径，不是复述。
- 手写零依赖 JSON-RPC（协议面只有 4 个方法），与本仓取向一致。
端点挂在 `AgentAuth` **之内**：必须与 /mail/send 同一套凭证，
否则就成了绕过收窄的旁门。
## 11 个工具，名字与参数与四桥逐字一致
`connect_to_server` 在这里只做一次真实读来确认连通性 —— 能调到它本身
就证明凭证已过（它是局内端点，不再需要 register）。
## ★ 端到端撞出并修掉的两个真 bug
**① `Tool.Run` 丢掉了身份**（本来写成 `context.Background()`）。
症状：每个工具调用都 Unauthorized，模型表现为「说连上了但读不到任何信」。
**② 路径参数没到位**：被包装的 handler 用 `chi.URLParam(r,"id")` 取 id，
而 `httptest.NewRequest` 造的请求**没过 chi 的路由** ⇒ `URLParam` 恒空
⇒ 任何带路径参数的工具都报「Invalid id」。
第②个的发现过程值得记：端到端测越权时，主人和越权者**都**返回
「Invalid id」。只看越权那一次会误判成「收得太紧」，进而把**正确的收窄改松**；
做对照才看出是参数没到位。
修法两处：`withRouteParams` 注入 chi RouteContext；`invoke` 里**不能**再
`WithContext(ctx)` —— 那会覆盖掉刚注入的 RouteContext。
**③ 发现并暴露了会话越权漏洞**（同批，单独提交 095213b）：
`AgentMayReadSession` 只比 `scope == target`，不问「你是不是参与方」，
而 session_id 由请求方给。对照实验 + 生产复核证实可读他人正文。
## 判据（13 格）
`internal/mcp/mcp_test.go`。真正在钉三件**只有集成才可能坏**的事：
1. MCP 不能成为越权旁门（工具参数里没有身份字段）。
2. 参数映射不许偷偷放宽/收紧（`attachment_ids` 被吞 ⇒ 附件静默不随信发出）。
3. 协议语义不许退化（工具失败必须 result+isError，不是 JSON-RPC error）。
`TestEveryErrorResponseCarriesID` 是被真 bug 逼出来的：曾用
`ID json.RawMessage` + `omitempty`，nil 时**整个 id 字段从 JSON 里消失**，
客户端会一直等这条的响应。遍历全部错误出口逐条验。
**变异验证**：
Run 丢身份 → 红 4
工具失败回 JSON-RPC error → 红 4
read_inbox 丢 workspace 收窄 → 红 1
id 泄露（tag+idPtr 同时失效） → 红 1 ★（真 bug 需两处同时失效，故两处防御都要留）
去掉 withRouteParams → 红 1
invoke 里加回 WithContext → 红 1
## 端到端（真实网关进程，临时库，备用端口 8199，不动生产）
未认证 /mcp → 401
错误密钥 → 401
initialize → 回显 2025-06-18
notifications/initialized→ 202 且无响应体
tools/list → 11 个，带 annotations 与 required
send_mail → read_inbox → mcp-peer 通过 MCP 读到对方发来的信
read_mail（带 session_id）→ 主人读到自己的信
## 未做
- 未删除旧桥 `plugins/zcode-mail-bridge/mcp/server.mjs`。它是 zcode 插件
清单里声明的入口（`.zcode-plugin/plugin.json` 的 mcpServers），删掉会破坏
该插件的组装。两者并存无害：桥仍走 HTTP，服务端这份是接入端零安装的那条路。
- 未部署（本提交只含代码）。
|
2026-10-02 13:28:07 +08:00 |
|
