security(analytics): read-scope 自动桥是插件顺序依赖的 — security 晚注册则 analytics RLS 静默全关

[os-zhuang]

写 #3597 的端到端门时发现的独立缺陷:analytics 的 read-scope 自动桥是插件注册顺序依赖的,顺序不利时整个 analytics RLS 静默关闭 —— 两条 strategy 都不加 scope。

代码与它自己的注释矛盾

packages/services/service-analytics/src/plugin.ts:277-306:

// ADR-0021 D-C — wire the read-scope provider. Prefer an explicit option;
// otherwise auto-bridge to a registered `'security'` service that exposes
// `getReadFilter(object, context)` (resolved at call time so plugin-init
// order does not matter).                                    ← 注释这么说
...
if (trySecurity()) {                                          ← 但赋值卡在 init 时刻的探测上
  getReadScope = (object, context) => trySecurity()?.getReadFilter(object, context);
  autoBridgedReadScope = true;
}

闭包本身确实是懒的,但它只在 security 于 init 时刻已存在时才被赋值。security 晚注册 ⇒ getReadScope 永远是 undefined ⇒ AnalyticsService.callCtx 直接 return this.baseCtx(analytics-service.ts:332)⇒ 无论 NativeSQL 还是 ObjectQL 都不加 scope。

两个兄弟桥都是对的,只有这个不是:

• executeAggregate(plugin.ts:181-182):"Probe now (warn if missing) but resolve at call time so plugin order does not matter"
• executeRawSql(plugin.ts:229-231):"Always wire the bridge — resolution happens at call time... This way plugin-init order does not matter"

影响面

生产 CLI 路径不受影响。 os serve 里 SecurityPlugin 在 packages/cli/src/commands/serve.ts:1658,AnalyticsServicePlugin 由 capability resolver 在其之后加载(静态表 serve.ts:303-305),顺序正确 ⇒ 桥接上。

受影响的是:

1. 自建 kernel 的 embedder —— 框架是按库分发的,谁把 AnalyticsServicePlugin 排在 SecurityPlugin 前面,谁就静默拿到无 scope 的 analytics。唯一提示是一条 WARN,而且那条 WARN 的措辞还把问题说小了(见下)。
2. 仓库自己的 bootStack harness —— packages/verify/src/harness.ts 里 AnalyticsServicePlugin 在 :159,SecurityPlugin 在 :232。整个 dogfood/verify harness 的 analytics RLS 一直是关的,所以在那里写的任何 analytics RLS 断言都是空过的。这正是我写 security(analytics): ObjectQLStrategy 不消费 getReadScope — NativeSQL 回落后聚合查询无 RLS/租户谓词(#2852 修复未覆盖的另一半) #3597 端到端门时撞上的:门先红了,红的原因不是 security(analytics): ObjectQLStrategy 不消费 getReadScope — NativeSQL 回落后聚合查询无 RLS/租户谓词(#2852 修复未覆盖的另一半) #3597,而是这条。

WARN 措辞也是错的

plugin.ts:463-467 说"the raw-SQL analytics path will NOT enforce tenant/RLS scoping on joined objects"。实际上没有 provider 时,所有路径、所有对象都不加 scope,不只是 raw-SQL、不只是联表。

复现

packages/qa/dogfood/test/analytics-rls.dogfood.test.ts(随修复一起提交):owner-scoped RLS fixture + 真实 HTTP + 非管理员 member。修复前 member 的聚合返回全表 5 行,修复后返回自己的 2 行;回退 plugin.ts 改动后 4 个用例红 3 个。

修法

getReadScope 无条件接线,只用 init 时刻的探测决定日志措辞 —— 与两个兄弟桥完全一致。

待核

cloud 是独立仓库,我没检查它的插件注册顺序。如果任何已发布的 composition 用了不利顺序,这条应升级到 p1。

---

🤖 Generated with Claude Code

[os-zhuang]

已核 cloud 仓插件顺序 —— 两个 composition,结论相反

（纯代码阅读，未启动 cloud 实测；未改动 cloud 仓任何文件。）

✅ 租户运行时:安全 —— 客户数据不受影响

packages/objectos-runtime/src/artifact-kernel-factory.ts:

• SecurityPlugin — line 480
• loadCapabilities(...) 加载 AnalyticsServicePlugin（capability-loader.ts:150）— line 676

676 > 480,security 先注册 ⇒ 桥正常接线。真实客户记录所在的运行时顺序是对的。

❌ 控制面:命中 —— 顺序不利

packages/service-cloud/src/control-plane-preset.ts 是一个有序数组（函数文档自称 "Build the ordered plugin list"）:

• §4 com.objectstack.service-analytics → line 224-227
• §5b com.objectstack.security → line 426-429

analytics 在 security 之前。lazyPlugin 只是把 import 做成懒的,内层 init 仍跟随数组顺序:

async init(ctx: any) {
  impl = await factory(ctx);
  if (impl?.init) await impl.init(ctx);   // ← 跟随注册顺序
}

⇒ analytics init 时 ctx.getService('security') 拿不到东西 ⇒ getReadScope 永不接线 ⇒ 控制面 analytics 无 RLS。

而控制面确实对外提供该路由 —— control-plane-preset.ts:169-170 自注:

cache / analytics ← foundational, zero idle cost (analytics also backs /api/v1/analytics/* dataset preview)

严重度建议:维持 p2,不升 p1

升级的理由不成立到 p1,因为:

1. 租户运行时顺序正确 —— 客户业务记录不在暴露面内。
2. 控制面暴露的是 dataset preview 面,承载的是 cloud 自身运营数据（tenant/environment/package/approval/marketplace),不是终端客户表数据。
3. 本仓修复（fix(analytics): make the read-scope auto-bridge order-independent + first real e2e RLS gate (#3618) #3619）对 cloud 是零改动生效的 —— cloud 只要 bump @objectstack/service-analytics 就闭合,不需要动 cloud 代码。

但仍建议 cloud 侧:

• 及时 bump 该依赖;
• 顺带把 control-plane-preset.ts 的 security 提到 analytics 之前(纵深防御 —— 不该让安全控制的生效与否取决于数组顺序,哪怕框架侧已经修好了)。

未验证

没有启动 cloud 控制面观察那条 WARN 实际出现,也没有验证控制面是否真有 RLS 敏感的 analytics 查询在跑。上述是代码路径推断。若要坐实,在控制面 boot 日志里 grep No getReadScope configured 即可一眼确认。