Repository navigation
安全:readonlyWhen 服务端剥离仅覆盖单条 update 路径,多行 updateMany 不强制(条件只读可被批量绕过) #3042
Description
Activity
修复已开 PR #3044(draft)。落地时核实出一处影响范围需要更正,如实同步:
范围校正:外部 REST/SDK 面其实已安全
本 issue 原文说「REST
POST /data/:object/updateMany对外可达 → 多行路径」——不准确。核实结论:protocol.updateManyData(REST/updateMany与 SDKupdateMany背后)是按 id 列表循环单条engine.update,每条走单条路径,而单条路径已经剥离readonlyWhen(L2431)。HTTP dispatcher / hono / SDK 的所有 update 入口也都是单条where:{id}。- 所以真正没被强制的是引擎的真·where 谓词多行路径(
options.multi=true),它只被编程式 / 嵌入式消费方触达:内部服务(lifecycle / messaging outbox / settings,均 system 上下文、本就豁免)、插件、以及embed-objectql这类直连 ObjectQL 的用户上下文调用方。
因此严重性低于初判:外部 HTTP 攻击面本就走单条、已安全;缺口在编程式多行面。但修复仍然值得做——它是三件事:(1) 对称性(静态
readonly在多行路径已剥离、readonlyWhen没有,属 declared≠enforced 的不一致);(2) 封堵编程式/嵌入式用户上下文多行调用;(3) 纵深防御,若将来有路由接上真·where 批量更新即已覆盖。实现(采纳方案 B 的精确变体,而非 A/C)
之前列的 A(无条件剥离)会误伤合法批量编辑;C(fail-closed 拒绝)与既有「静默剥离、兼容优先」取向不一致。最终实现是精确但仍批量安全的变体:
- 多行路径仅当载荷确实写了
readonlyWhen字段时,用与写入绑定的同一个已组合 AST(含 RLS/sharing 行级过滤)读回匹配集(一次查询); - 剥离「在 ≥1 匹配行谓词为 TRUE」的字段——批量载荷无法分行差异化,故任一目标行锁住即对整批 fail-safe 丢弃;
- 无任一匹配行锁住的条件字段照常写入(合法批量编辑零回归);
- 与单条
stripReadonlyWhenFields、静态 readonly 多行剥离对称,INSERT 豁免不变。
证明层级(据校正后的面选取)
集成测试直接驱动真实的
objectql.update(..., {multi:true, where})多行路径——这才是真实受影响面。HTTP dogfood 测试不会经过此路径(循环单条),加了会误导,故不加。objectql 全套 898 通过。CI 绿后合入,issue 随 PR 关闭。
Generated by Claude Code
- added a commit that references this issue
on Jul 16, 2026 - added a commit that references this issue
on Jul 17, 2026 - added a commit that references this issue
on Aug 8, 2026 - added a commit that references this issue
on Aug 31, 2026 - added a commit that references this issue
on Sep 1, 2026
概述
readonlyWhen(条件只读)的服务端剥离 只在单条 by-id update 路径上运行;options.multi的 多行updateMany路径不做readonlyWhen剥离。因此一个命中readonlyWhen条件、本应被锁的字段,可以用一次多行更新绕过——例如「invoice 变 paid 后锁tax_rate/ 锁行项」这类条件锁,PATCH … /updateMany就能改写。这是 #3003 / #2948 的同族问题:静态
readonly: true的剥离(#2957)已同时覆盖单条 + 多行两条路径,但readonlyWhen的剥离只补了单条路径,两者不对称。定位
packages/objectql/src/engine.ts,update():hookContext.input.id分支):stripReadonlyWhenFields(...)✅stripReadonlyFields(...)(静态 readonly,非 system)✅options.multi && driver.updateMany路径(L2427 起):stripReadonlyFields(...)(静态 readonly)✅stripReadonlyWhenFields(...)❌REST 侧多行入口存在且默认开启:
packages/rest/src/rest-server.tsL6075POST /data/:object/updateMany(operations.updateMany默认 true,L1646),所以该路径对外可达。根因
stripReadonlyWhenFields需要 prior record 求值合并态{...previous, ...data};多行路径出于成本考虑不逐行 fetch prior record(现有代码对state_machine/cross_field规则同样只logger.warn跳过,见 L2434-2436),readonlyWhen顺势没接上剥离。期望行为
多行 update 也应强制
readonlyWhen,与单条路径及静态readonly的多行覆盖对称。需要决策实现方式:readonlyWhen的字段,若出现在载荷里就无条件剥离(不看 per-row prior,等价「宁可锁死」)。对「锁字段」语义通常可接受,但对少数readonlyWhen依赖行间差异的场景会误剥。state_machine/cross_field多行强制是同一笔账,可一并解决(去掉那处 warn 跳过)。readonlyWhen或 object-level 转换规则的对象」在多行 update 上 fail-closed 拒绝,把 warn 升级为 error。倾向 A 或 C 作为短期封堵(和「剥离优先、兼容性好」的既有取向一致),B 作为长期精确解。
关联
readonlyWhen对称缺口 + 多行路径面engine.tsL2434-2436 多行state_machine/cross_field跳过的 warn —— 同一笔「多行路径不强制转换类规则」的账