fix(analytics): scope the dimension-label lookup to the referenced object's RLS (#3602 residual 1)

[os-zhuang]

#3602 残留 1。写 #3597 端到端门时定性的那个更窄的真实泄露,单独修。

泄露

数据集按 lookup/master_detail 维度分组时,analytics 要把分组的 FK id 解析成关联记录的显示名 —— 走的是一次"按 id 分组"的 per-record 读,套在 aggregate 桥上(plugin.ts 的 fetchRecordLabels)。这次读不带任何 read scope。

• id 来自 security(analytics): ObjectQLStrategy 不消费 getReadScope — NativeSQL 回落后聚合查询无 RLS/租户谓词(#2852 修复未覆盖的另一半) #3597 之后已加 scope的聚合结果,所以同对象、以及"被引用对象更宽松"的情形本就安全;
• 但当被引用对象的 RLS 严于基对象时(用户能看自己的 deal,却无权直接读它指向的某个 vendor),取名就会泄露用户读不到的关联记录名。这是真实的窄跨对象泄露。

修法(自足,不碰 spec)

取名读现在应用被引用对象自己的 read scope —— 用 aggregate 路径同一个 getReadScope provider 绑定到本请求,$and 组合(非 key 合并,id 谓词顶不掉它)。fail-closed:该对象 scope 解析失败则跳过这一维的取名(渲染原始 id),绝不无 scope 取。无 provider 时行为不变。

改动全在 service-analytics 内:DimensionLabelDeps.fetchRecordLabels 加可选 scope、resolveDimensionLabels 加可选 resolveScope,都是包内部类型,不动 spec 契约。

测试

• dimension-labels 单测(4):证明被引用对象的 scope 被穿进 fetchRecordLabels;resolveScope 抛错时fail-closed 跳过取名(不发生无 scope 读);select 维度不受影响;无 resolver 时维持旧行为。
• query-dataset 集成(1):getReadScope 按对象返回不同 scope,断言取名收到的是被引用对象 crm_account 的 scope 而非基对象的 —— 回退 analytics-service.ts 接线即变红(已验)。
• service-analytics 184 passed(原 179 + 5);tsc 无新增错误(2 个存量在未触文件)。

一并做的诚实更正(见 #3602 评论)

引擎侧独立追查确认 engine.aggregate 根本没有 join/lookup 遍历能力。因此:

• 我在 analytics: 让 executeAggregate 桥携带 ExecutionContext(#3597 的纵深防御第二层)+ 两处残留无 scope 调用 #3602 原文和 fix(analytics): enforce read scope on the ObjectQL aggregate path (#3597) #3601 注释里"传 context 可解掉联表 fail-closed / engine 经 lookup 遍历"的说法是错的,已在 analytics: 让 executeAggregate 桥携带 ExecutionContext(#3597 的纵深防御第二层)+ 两处残留无 scope 调用 #3602 评论更正;
• analytics: 让 executeAggregate 桥携带 ExecutionContext(#3597 的纵深防御第二层)+ 两处残留无 scope 调用 #3602 主项(穿 ExecutionContext 作纵深防御第二层)重估后建议 won't-do:join 解锁的理由已塌,只剩基对象"同一条谓词加两遍",还背 double-scoping 发散风险 + spec 门成本;
• 附带暴露一个既有功能缺口(与 RLS 无关):跨对象聚合在 ObjectQL 回退路径上本就不工作(SQL 报错 / (null) 静默塌桶),值得单独跟进。

本 PR 只做残留 1。残留 2(generateSql 补 WHERE,纯展示)未做,优先级最低。

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Jul 27, 2026 12:58pm

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): packages/qa, packages/services.

8 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:

• content/docs/automation/webhooks.mdx (via packages/services)
• content/docs/kernel/runtime-services/audit-service.mdx (via packages/services)
• content/docs/kernel/runtime-services/index.mdx (via packages/services)
• content/docs/kernel/runtime-services/settings-service.mdx (via packages/services)
• content/docs/permissions/authorization.mdx (via packages/qa)
• content/docs/permissions/delegated-administration.mdx (via packages/qa)
• content/docs/plugins/packages.mdx (via packages/services)
• content/docs/protocol/kernel/i18n-standard.mdx (via packages/services)

Advisory only. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs origin/main → pass the list as args.docs.

[os-zhuang]

补充:加了一个真栈 e2e 门 analytics-label-scope.dogfood.test.ts —— 之前的单测/集成测试都 fake 掉了 fetchRecordLabels,这个门专门覆盖插件里真实的取名闭包(把被引用对象 scope $and 进 id filter)。

两对象 owner-scoped fixture:member 拥有一个指向admin 名下 vendor 的 deal。按 vendor 分组、把 id 解析成名字时会读 vendor 对象,而 member 读不到它。断言 member 拿到 vendor 原始 id(名字不泄露),admin(拥有该 vendor)仍拿到解析后的名字 —— 证明是加 scope 而非一律清空。回退插件的 scope 应用后,member 直接拿到 Admin-Owned Vendor(复现泄露)。

完整 dogfood 门 62 files / 357 tests 全绿。