Skip to content

finding: ExecutionContext 在 dispatcher / REST / share-link 三处独立组装 —— 收敛为单一共享装配函数前,先裁决匿名面分歧 #6216

Description

@qq9340100

事实(均可对照代码与 PR 实读)

ExecutionContext 目前在 三处 各自手工组装,字段集合靠人肉对齐:

  1. dispatcher 面(/mcp 通道):完整组装,含 principalKind(human/agent 可达,acceptOAuthAccessToken 是 agent 唯一入口),匿名请求产出 guest ctx
  2. REST 面(packages/rest/src/rest-server.ts computeExecCtx):两处手写的 ExecutionContext 组装已漂移:REST 传输不带 principalKind / onBehalfOf,而 explain / security 会读它 #6071 / PR fix(rest): REST 面的执行上下文补齐 ADR-0090 D9/D10 的 principal 分类 (#6071) #6205 刚补齐 principalKind: 'human'(该 PR 的 rest-server.ts 行内注释记录了 agent/guest 在此面不可达的完整证据链,是本单的 provenance 起点)。匿名请求 返回 undefined(无 ctx,上游 401)。
  3. plugin-sharing / share-link 面:第三处独立组装,已发现掉字段实害——accessible_org_ids 缺失导致 group 姿态 fail-closed 403(已单独立案 同族第三处组装:share-link 路由把授权信封裁成 4 个字段后直接当 enforcement context 喂给 engine.find —— group 租户姿态下 Layer 0 墙恒判否 #6206)。

为什么立此单

#6071 正文的「建议方向」提出把组装收敛为单一共享函数,但该文本随 #6071 关闭而沉没;#6071 的 dev 明确不擅自开重复单、请 PM 裁量,故由 cli 车道 PM 以 finding 立案存档。三处手工组装已经产生过两类真实缺陷:字段漂移(#6071 的 principalKind 缺失)与字段丢失(#6206 的 accessible_org_ids),收敛是消除此类缺陷的结构性解。

设计前提(收敛前必须先裁决,这是真正的 blocker)

匿名面分歧:dispatcher 对匿名产出 guest ctx,REST 对匿名产出 undefined(fail 到 401)。一个共享装配函数必须先回答「匿名到底是 guest ctx 还是无 ctx」——这不是实现细节,而是授权语义裁决(牵动 explain-engine.ts guest⇒EXTERNAL 等执法消费者)。在裁决之前直接抽共享函数,只会把分歧固化进签名或塞进布尔开关。

建议路径

  1. 先出一页匿名语义裁决(guest ctx vs no-ctx,或显式双模式并写明各自消费者);
  2. 裁决后抽单一装配函数,三面接入,字段集合由类型收紧(新增字段漏接直接编译红);
  3. 同族第三处组装:share-link 路由把授权信封裁成 4 个字段后直接当 enforcement context 喂给 engine.find —— group 租户姿态下 Layer 0 墙恒判否 #6206 的修复可先行(实害止血),但实现时向本单的收敛方向靠拢。

关联

Finding 立案,未指派、未标域——由 triage 席分诊。

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions