为多用户插件提供可替换认证与结构化订阅授权扩展点

[dake6767]

我们在开发 DSH 多用户插件，希望通过受支持的扩展点实现认证、对象授权和流隔离，并减少对宿主内部结构的运行时包装。

基于 dsh-v0.1.3-alpha.1（d347e703）的源码核查，目前 Connection 已提供浏览器认证，Gateway 在 WebSocket 升级时也执行认证检查。不过，多用户插件要接入自己的登录体系和对象访问规则，仍需要包装认证入口、部分 controller 方法，并介入 WebSocket 处理。

相关讨论 #5790、#5791 已提出请求上下文传播；#2679 描述了更广泛的多用户需求。这里希望进一步确认以下扩展方向是否符合 DSH 的架构：

1. 可替换的认证接入。 允许插件解析可信主体，同时保留宿主的 Host／Origin 检查；原生单用户认证继续作为默认实现。
2. 统一的调用与订阅授权入口。 在 Remote 调用、逻辑流订阅建立前提供检查点，并明确主体在异步执行和流迭代中的可用范围。
3. 结构化的流隔离能力。 允许按主体生成或过滤工作区、会话等共享流的 baseline 与增量，使插件无需读取私有升级路由表或解析、改写原始 WebSocket 帧。
4. 明确撤销与覆盖语义。 说明登录失效或权限撤销如何影响已有订阅，以及这些扩展点覆盖哪些入口；未覆盖的原始 HTTP 路由应明确由谁负责保护。

账户、角色、内容归属和具体授权策略仍由插件负责。希望宿主提供的是可依赖的执行位置与生命周期，而不要求内置完整多租户产品或分布式执行平台。

建议以双用户并发调用、交错流消息、跨用户订阅拒绝、已有连接撤销及插件卸载作为契约测试场景。这些是建议的验收条件，本帖不宣称相关上游实现已经完成。

维护者是否认可这一方向？是否适合先从可替换认证和请求上下文开始，再单独推进结构化订阅授权？

[argszero]

这帖把问题问到了点子上——"希望宿主提供可依赖的执行位置与生命周期，而不是内置完整多租户产品"正是 dsh 的插件哲学（注册即效果、disposer 即生命周期）。我按 master d347e70390 把你们列的四个方向逐一对照了源码，先给现状地图，再说排序建议。

现状锚点（源级核实）

认证面今天有两处，判定逻辑都在 core 内、无插件替换点：

1. Connection 载体的浏览器会话认证 —— packages/client/connection/src/browser-auth.ts：默认单用户认证 = HMAC 签名 cookie（payload v1 绑定 authority，即 Host）+ process-launch token + 浏览器 trust 流程；
2. Remote stream 升级即拒 —— packages/api/gateway/src/stream-server.ts:213 rejectRemoteStreamUpgrade(socket, 401|403)：WS 升级在移交 ws 前就结束。这是你说的"Gateway 在 WebSocket 升级时执行认证检查"。

所以方向 1（可替换认证）成立与否取决于 core 是否愿意把这两处的决策点（"这个请求可信吗、主体是谁"）从实现里抽成可注册的缝——判定留在插件、Host/Origin 检查留在宿主。技术上不难，难在默认实现与插件实现的分工边界要写清楚。

请求上下文是方向 2/3/4 的公共前提，且目前确实缺失。 Remote 调用（JSON-RPC over remote stream）与逻辑流订阅的派发路径都不携带 HTTP request；插件"包装认证入口 + 部分 controller 方法"就是在这个缺口上打补丁。相关讨论 #5790/#5791 已经证了同一件事（RPC/WS 派发丢 request），我在那边提的 ALS（currentConnectionRequest()）就是"让 async 执行与流迭代中能拿到可信主体"的最小载体——先有 principal，才能谈"在调用与订阅建立前放检查点"。

订阅注册缝是单槽的。 packages/api/gateway/src/index.ts:238-244 registerRemoteEvents 只允许一个应用选择的转发源（Host 持有唯一槽）。要做"统一订阅授权入口"，检查点必须建在 gateway 派发层而不是插件层——这与 Remote 事件转发扩展（registerForwardedEvent 提案）同构：需要 gateway 级注册集合 + 每订阅者身份，缺一不可。

流隔离 = 产生侧过滤，现在没有变换缝。 现有 mux 是单一 carrier 上多逻辑流，事件发射是 emit-only（session/event 订阅没有"按订阅者改写/过滤"的缝）。按主体生成/过滤 baseline 与增量的正确位置在产生侧——消费侧投影过滤只治标（且会重蹈"UI 消费事件≠产生数据事件"那类陈旧问题）。

撤销语义依赖主体标识，同样排在 principal 之后。 插件卸载带走注册（disposer 语义现成），但"登录失效→已有订阅撤销"无从谈起——订阅者身份未知，连"撤销谁的"都定义不了。approval/session-close 事件存在，但事件不带主体。

排序建议

同意你的判断：先可替换认证 + 请求上下文，再单独推进结构化订阅授权。理由：方向 2/3/4 全都要"主体是谁"做参数；没有 principal 时，订阅授权检查点、流过滤、撤销覆盖全是空转。请求上下文不用新造轮子——#5790/#5791 的 ALS 提案 + #5853 的嵌入式/桌面 token 可达性讨论是同一个收敛点（可替换认证缝同时服务桌面 launcher 场景：浏览器 cookie 之外需要进程内 token 的获取途径）。

验收场景（双用户并发、交错流消息、跨用户订阅拒绝、已有连接撤销、插件卸载）是好的契约测试面；补充一点：它们不依赖多租户部署，同一进程内双 Connection/双主体的 host 级测试就能覆盖大部分——这与 #5829 的多实例反代场（16-instance，browser-auth 门全 401）互为补充，后者验证"反代证 host 非 user"的边界。

插件面判定：这四方向本质是 core 扩展点提案（认证决策点、principal 上下文、mux 产生侧过滤、派发层订阅授权），不是今天能用插件补上的缺口；但方向确认后，插件可以承担策略侧（谁被允许、按什么对象规则），core 提供机制侧（何时被问、主体是谁）——与现有社区插件形态（侧边栏、审批、只读 preset）互补。若维护者认可，建议先从"可替换认证 + 请求上下文"落一个最小缝（哪怕默认实现先行），订阅授权作为第二阶段单独设计。