[17.0-rc2验收] autonumber 字段可被普通调用者改写:POST 提交显式值绕过序列、PATCH 直接改号落库 —— readonly 剥离不保护 type:'autonumber'

[yinlianghui]

现象

非 system 上下文的普通 REST 调用者可以自由指定和改写 autonumber 字段的值:

• POST /data/:object 携带显式 autonumber 值 → 被原样落库(序列被绕过);
• PATCH /data/:object/:id 携带 autonumber 字段 → 200 且改写落库(业务单号被篡改)。

而引擎自己的文档说得很清楚(packages/objectql/src/engine.ts applyAutonumbers 注释):"Required-validation exempts autonumber either way, so a required record number is never rejected for 'missing' — the runtime owns the value, not the client." —— 运行时声称拥有这个值,但写路径没有任何一层阻止客户端提交/改写它。

复现步骤(HotCRM 17.0-rc2 验收环境,admin token,SQLite file 驱动)

# 1) POST 显式提交 autonumber → 被采纳,序列绕过
curl -X POST :4092/api/v1/data/crm_account -H "Authorization: Bearer $TOK" \
  -d '{"name":"AN forge","account_number":"ACC-777777"}'
# → 201, record.account_number = "ACC-777777"

# 2) PATCH 改写既有单号 → 200,回读已变
curl -X POST :4092/api/v1/data/crm_account -d '{"name":"AN1"}'   # → ACC-000012
curl -X PATCH :4092/api/v1/data/crm_account/<id> -d '{"account_number":"ACC-888888"}'  # → 200
curl :4092/api/v1/data/crm_account/<id>   # → account_number = "ACC-888888"

# 3) 同样在 crm_product 复现
curl -X PATCH :4092/api/v1/data/crm_product/<id> -d '{"product_code":"PRD-8888"}'  # → 200,回读 PRD-8888

两次独立运行均复现;在 HotCRM 的 7 个对象上逐一验证了 PATCH 改写(account_number / product_code / campaign_code / member_number / contract_number / quote_number / attendee_number),机制上同样适用于 crm_case.case_number(8 个 autonumber 字段全部暴露)。

对照:同批测试中所有真正声明 readonly: true 的字段(name_normalized、line_number、is_closed、seed_key、view_count…)PATCH 均被正确剥离(200 但值不变)——剥离机制本身工作正常,只是 autonumber 不在保护范围内。

期望 vs 实际

• 期望:autonumber 是运行时生成的业务标识,非 system 写入中的调用者提交值应像 readonly 字段一样被剥离(insert 与 update 都是);
• 实际:insert 端 applyAutonumbers 显式 "respect explicit value"(if (current != null && current !== '') continue),SQL 驱动路径同样采纳显式值;update 端 stripReadonlyFields 只看 def.readonly,autonumber 字段没有该标记,直接放行。

落点分析

• packages/spec/src/data/field.zod.ts:895 —— autonumber: (config) => ({ type: 'autonumber', ...config }),builder 不隐含 readonly: true;
• packages/objectql/src/validation/rule-validator.ts stripReadonlyFields —— if (!def?.readonly) continue;,按字段级 readonly 标记剥离,type === 'autonumber' 不参与;
• packages/objectql/src/engine.ts applyAutonumbers(约 1829-1885)—— 只在值为空时生成,显式值原样保留;SQL 驱动 supports.autonumber 路径实测同样采纳调用者显式值(上面复现 1)。

影响

• 业务单号(合同号、报价号、工单号……)可被任何有对象写权限的调用者伪造/改写,审计与对外引用失去锚点 —— 与已修复的 data: created_at is client-writable on an ordinary PATCH — the audit anchor can be forged silently #4447(created_at 可被普通 PATCH 伪造)同一缺陷族;
• 大多数对象的 autonumber 列没有唯一索引(HotCRM 仅 crm_case 声明了 (organization_id, case_number) 复合唯一),伪造会产生静默重号;
• 在有唯一索引的对象上,把号改到序列尚未发出的值,会让后续正常插入在追上该值时撞唯一约束 —— 与 Autonumber counter neither syncs to MAX(existing) per tenant nor re-checks on collision — warm-DB creates 409 in bursts, each failure burning a number (25 retries observed) #5495 / hotcrm#698 的 409 风暴叠加放大。

建议方向

写路径将 type: 'autonumber' 视为隐含 readonly(非 system 上下文一律剥离,insert 与 update 同权),或在 spec 层为 autonumber builder 注入 readonly: true 并让 applyAutonumbers / 驱动序列继续豁免 system 写(import/seed 的 preserveAudit 类场景可沿用现有白名单机制)。

环境

hotcrm@0899b4f + @objectstack 17.0.0-rc.2(pnpm exec objectstack dev,file:SQLite,--seed-admin)

查重:搜过 autonumber(24 条)、readonly autonumber/account_number/quote_number、autonumber overwrite/writable/forge,两仓 open+closed 均无本缺陷(#5495/#698 是序列计数器不同步问题,#4903 是 readonly 剥离与 hook 补写不对称,均不覆盖「autonumber 无写保护」)。

[os-zhuang]

分诊结论：pm:queue / domain:engine

事实核查（已对照 origin/main 当前代码，非工作区）：

• packages/objectql/src/validation/rule-validator.ts:618 stripReadonlyFields 中 if (!def?.readonly) continue; —— 仅按字段级 readonly 标记剥离，无任何 type === 'autonumber' 分支，与 issue 描述完全一致。
• packages/objectql/src/engine.ts:1861 applyAutonumbers 中 if (current != null && current !== '') continue; // respect explicit value —— 显式值原样保留，且该函数没有对非 system 上下文做任何拦截。
• packages/spec/src/data/field.zod.ts:895 autonumber: (config) => ({ type: 'autonumber', ...config }) —— builder 确认不隐含 readonly: true。

三处均在 origin/main 最新提交（28ad90e）下逐行核实存在，前提未被任何已合并 PR 修复，问题真实存在。

去重：搜索 org 内 open issues/PRs（autonumber、stripReadonlyFields、applyAutonumbers、account_number/quote_number/product_code writable 等关键词），未发现重复或在途 PR；#4447/#4511 是同族但已修复的 created_at 伪造问题（不覆盖 autonumber），#5495/hotcrm#698 是序列计数器不同步问题，均不构成重复或阻塞。

分类理由：有明确文件落点（rule-validator.ts / engine.ts / field.zod.ts）、可复现的 curl 步骤、清晰的期望-实际差异，属于「有明确文件/位置的具体缺陷」→ pm:queue。

领域理由：修复的核心落点是 packages/objectql（写路径的 readonly 剥离与 autonumber 生成逻辑）与可选的 packages/spec（builder 层隐式 readonly），均属 domain:engine 映射表内的 packages/objectql / packages/metadata*。SQL 驱动路径涉及的是 driver-sql（非 driver-memory/driver-mongodb），不落入 #5499 的冻结范围，正常入列。

「本评论来自分诊座位 Routine（#5474 试点），不构成认领」。

---

Generated by Claude Code

[os-zhuang]

认领:PM 循环第 1 轮(engine-core 车道)
会话:session_01V7WetGmnfoXNn8cLieKKmx
分支:claude/issue-5503-autonumber-readonly-strip
Worktree:objectstack-issue-5503
域:domain:engine-core
文件面:packages/objectql/src/validation/rule-validator.ts、packages/objectql/src/engine.ts(写路径)、objectql 测试、.changeset/*.md。⛔ 不碰 packages/spec(builder 层若需注入 readonly: true 属 spec 座位,另行移交)、不碰 packages/plugins/driver-*(修在引擎层,驱动无关)。

---

Generated by Claude Code

[os-zhuang]

实现完成，草稿 PR：#5627（分支 claude/issue-5503-autonumber-readonly-strip，会话 session_01V7WetGmnfoXNn8cLieKKmx）。

前提已用可执行复现证明成立：新测试文件在未改动源码上跑出 9 红 / 8 绿 —— 9 条正是 issue 描述的三类现象（POST 显式值落库、PATCH 改号落库、supports.autonumber 驱动路径同样采纳显式值），8 条绿的是 isSystem / preserveAudit / 钩子写入的豁免语义，改动前后都保持绿。

修法按约束落在引擎/校验层：stripReadonlyFields 的判定扩展为「作者声明的 readonly 或 运行时拥有的字段类型」（isRuntimeOwnedField），INSERT 侧新增更窄的 stripRuntimeOwnedFields（不接管 #3413 留在入口的作者声明 readonly 语义）。剥离发生在派发之前，因此 SQL 驱动路径天然被覆盖 —— 测试直接断言递交给 driver.create 的负载里没有这个键，未改动任何 driver。packages/spec 未触碰。

顺带记录了一条观察类发现 #5628（autonumber builder 不注入 readonly: true，导致 readonly 契约的「表单不可编辑」那一半对单号字段不成立），已按无 pm:queue 的 finding 归档，不在本 PR 内扩大范围。

---

Generated by Claude Code

[os-zhuang]

复核通过,ACCEPT(engine-core 车道 PM,第 1 轮):PR #5627。

交付:引擎/校验层把 type: 'autonumber' 视为运行时拥有 —— UPDATE 侧 stripReadonlyFields 判定扩展(isRuntimeOwnedField,单行与 multi 共用剥离点),INSERT 侧新增更窄的 stripRuntimeOwnedFields 跑在校验之前,刻意不接管 #3413 留在 DataProtocol 入口的作者声明 readonly 语义;剥离发生在派发给任何驱动之前,SQL 驱动序列路径用「递交给 driver.create 的行里没有该键」的断言证明覆盖,driver-* 零改动。豁免语义(isSystem / preserveAudit #3493 / 钩子)原样保留且有钉。前提用可执行复现证明(未改源码 9 红),反向验证 13 红与预测一致,空绿隐患($ne 不被内存驱动识别)已排除。engine.insert 的 onFieldsDropped 待办(#3407)按其注释要求接上,createManyData/insertManyData 补转发(逐行精度)。

两点记录:

• 文件面越出认领申报:metadata-protocol/src/protocol.ts(+34/−11,监听器转发)。功能上是剥离点接监听器的必要配套、仍在本车道,接受;由此 fix(objectql): autonumber 是运行时拥有的字段，写路径不再接受调用者提交的单号 (#5503) #5627 与 fix(metadata-protocol): 元数据保存的 422 保留 union 分支处方,Studio 重新拿得到字段名 (#5364) #5596 同触 protocol.ts,落地串行:fix(metadata-protocol): 元数据保存的 422 保留 union 分支处方,Studio 重新拿得到字段名 (#5364) #5596 先入队,本 PR 随后合 main 重验再入队,两个 PR 的意图叠加(fix(metadata-protocol): 元数据保存的 422 保留 union 分支处方,Studio 重新拿得到字段名 (#5364) #5596 改 saveMetaItem 422 区域,本 PR 改 createManyData/insertManyData 区域,预计文本不相交)。
• 顺带发现 [观察] autonumber builder 不注入 readonly: true —— readonly 契约的「表单不可编辑」那一半对单号字段不成立 #5628(spec builder 不注入 readonly:true,渲染层会把单号画成可编辑输入)已立单为 finding,归 spec 座位裁决,与本 PR 的引擎侧防线互补不冲突。

当前 ESLint 红为 #5604 已知签名;base 已恢复(2614aef),待 #5596 落地后本 PR 做同步圈 → 红清零 → 转 ready 入队。

---

Generated by Claude Code