updateMany 让请求体覆盖路径上的 object —— 暴露闸门查的是 A,写进去的是 B #3933

从 #3897 的修复里带出来的:那个 issue 的成因是"body 展开在受信任的值之后",而同一个展开在同一段代码里还覆盖了另一个东西 —— 路径上的 object。

代码

packages/rest/src/rest-server.ts:6820(updateMany 路由):

const result = await p.updateManyData!({
    object: req.params.object,   // ← 受信任的值,先写
    ...req.body,                 // ← body 展开在它之后,可以把它替换掉
    ...(environmentId ? { environmentId } : {}),
    ...(context ? { context } : {}),
});

而它上一行的闸门读的是路径上的对象名 —— enforceApiAccess 里 const objectName = req?.params?.object(rest-server.ts:1211)。所以 enable.apiEnabled / enable.apiMethods(ADR-0049 / #1889)是在 A 上判的,updateManyData 拿到的是 body 里的 B。

实跑复现

在 CRM dev 环境(pnpm dev:crm -- --fresh),已登录的普通调用者:

POST /api/v1/data/crm_account/updateMany
{"object":"crm_contact","records":[{"id":"gg92PD4PHl4XM-ol","data":{"last_name":"PWNED"}}]}

→ {"success":true,"operation":"update","total":1,"succeeded":1,...}
→ crm_contact 那条记录的 last_name 确实变成了 PWNED

路径指向 crm_account,写进去的是 crm_contact。把路径换成任意一个 apiEnabled 开着的对象,body 里填一个 apiEnabled:false 或 apiMethods 不含 update 的对象,闸门就整个绕过去了 —— 闸门在 A 上放行,写落在 B 上。

要说明的是这不是一个越权写:引擎中间件仍然按 B 跑 RLS/FLS,assertObjectRegistered 也仍然按 B 查注册表。破的是 apiEnabled/apiMethods 这一层 —— 也就是 ADR-0049 明确要求"声明了就必须真的拦得住"的那一层(Prime Directive #10)。

第二件事:body 里的 context

同一个展开也接受 context。它排在 ...(context ? { context } : {}) 之前,所以只要 resolveExecCtx 解析出了 context,真 context 就会盖回去 —— 我在已登录的会话上试过,updated_by 写的是真实用户 id,body 里的 {"isSystem":true} 没有生效。

有风险的是解析不出 context 的那一档:requireAuth: false 的部署上匿名请求走到这里,context 是 undefined,body 里那个就成了唯一的 context,原样喂给引擎当执行身份(isSystem / userId / roles 都在里面)。这一档我没有实跑复现,只是从 ?: 的短路条件上读出来的,需要一个匿名可达的部署才能量化。

范围

同一批路由里只有 updateMany 中招:

修法

跟 #3897 同一招,而且刚好是同一个教训的两半:受信任的值最后写。把 body 按契约 .parse()(UpdateManyDataRequestSchema,Zod 默认剥未知键,顺手把 context 挡在门外),再把 object: req.params.object 放在展开之后,让路径上的对象名成为唯一的答案 —— 闸门查的和写进去的从此是同一个对象,不是靠调用者不去填那个键。

_{核对于 origin/main @ 98e7cc7,crm_contact 那条实跑于 claude/delete-many-data-options-override-1wbjzj 上 #3897 修复后的构建。}