dsh web：Launch Token 兑换 Cookie 后仍可复用，是否支持一次性兑换或短时过期？

[wuzi-spark]

使用 dsh web 时，我们注意到启动链接中的 ?token=... 在兑换浏览器 Cookie 后，原链接仍可再次使用。想确认这是预期设计，还是有现成配置或扩展方式可以使 Token 在成功兑换后立即失效。

源码依据

查看 browser-auth.ts（commit 5dda764）：

• processLaunchToken() 为同一进程上下文复用 Token。
• authorizeIndex() 校验 Token 后返回 303、Set-Cookie 和跳转到 /，但未看到将 Token 标记为已使用、轮换或检查独立过期时间的逻辑。
• Cookie 有独立的签名和有效期，因此让兑换 Token 失效，理论上无需使已签发的 Cookie 失效。

这里关注的是同一 DSH 进程运行期间的重复兑换，不是声称 Token 跨进程重启永久有效。

复现核对步骤

1. 启动 dsh web，保存带 Token 的启动链接。
2. 在浏览器 A 打开链接，确认响应签发 Cookie 并跳转到不带 Token 的地址。
3. 保持 DSH 进程运行，在完全独立、没有该站点 Cookie 的浏览器 B 中打开原链接。
4. 检查是否仍能再次获得 Cookie 并访问页面。

我们观察到了原链接重复打开仍可访问；上述独立浏览器步骤用于排除已有 Cookie 导致的放行。根据当前源码，预计同一有效 Token 可以再次兑换，欢迎维护者确认。

风险与期望

即使不是云端部署，只要其他人能够访问同一个 DSH 地址，带 Token 的链接一旦被误转发、截图或记录在日志中，对方仍可能在原用户已经登录后，用旧链接建立自己的浏览器会话。跳转去掉 URL 参数可以减少暴露，但不会撤销已经泄露的 Token。

希望可以选择：Token 仅用于一次登录兑换，成功时原子地消费，之后拒绝重复兑换；已签发且有效的 Cookie 继续工作。未使用的 Token 也可配置较短有效期。

想请教的问题

1. 当前是否已有一次性兑换、短时有效期或主动撤销 Launch Token 的配置/推荐方案？
2. 能否通过官方支持的 Host 插件扩展点，在签发 Cookie 时消费 Token？目前看到 ctx.connection.authorizeIndex()，但未发现明确的兑换钩子。
3. 若需要修改核心模块，是否考虑支持上述能力，并提供不重启 DSH 的安全补发方式，用于更换浏览器、清理 Cookie 或首次兑换响应丢失？

我们理解一次性 Token 无法阻止泄露后被他人抢先兑换；本问题主要希望缩短凭据暴露窗口并阻止成功兑换后的重放，而不是关闭认证。

相关讨论：远程/反向代理场景的浏览器认证 #5828、Token 认证配置诉求 #5631。这里重点询问一次性消费和安全扩展方式。

[PerryLink]

结论：你观察到的行为与源码一致，而且这是当前设计，不是 bug：launch token 是"进程级共享密钥"，不是一次性兑换凭据；DSH 目前既没有"兑换即消费"，也没有 token 级 TTL。

源码依据（packages/client/connection/src/browser-auth.ts）

1. 同一进程恒定一个 token：PROCESS_LAUNCH_TOKENS = new WeakMap<object, string>() + processLaunchToken(owner) 按 ctx.root 缓存一个 32 字节随机值，已存在就直接返回；进程重启才换新值。
2. 兑换本身无状态：authorizeIndex() 只要满足 GET / + 恰好一个 token 参数（timingSafeEqual 比较）就重新签发 cookie 并 303 到 /；代码里没有"已使用"标记、没有 nonce 表、没有 token 过期时间。
3. cookie 独立有效：cookie 形如 v1.<base64url(payload)>.<HMAC-SHA256>，payload 绑定 authority（Host）+ issuedAt/expiresAt，属性 HttpOnly; SameSite=Strict; Max-Age=cookieMaxAgeDays（默认 30 天，schema 为 z.natural().min(1).default(30)，见 packages/client/connection/src/index.ts）。签名密钥持久化在 credentials 的 client-connection/browser-session 记录里，所以重启进程不会让已签发的 cookie 失效。

这个"进程内恒定"看起来是有意为之：源码特意用 WeakMap 让 token 跨 Connection 重载复用，设计目标更像是"启动时打印一个口令，进程存活期间多浏览器/多设备都能用"。

你问的三点

1. 现成配置：没有一次性兑换，也没有 token 级 TTL。唯一相关的旋钮是 cookieMaxAgeDays（默认 30，最小 1），它只影响签发出去的 cookie 寿命，不影响 token 可重复兑换。
2. 扩展点：目前没有。ctx.connection 暴露的是 carrier 的 RPC/Fetch 注册（ConnectionFetchRoute），authorizeIndex() 由 carrier 直接调用，认证判断在 BrowserAuth 内部，没有 pre/post 钩子能在"签发 cookie 时消费 token"。
3. 核心改动：值得做，而且实现面很小——在 BrowserAuth 里维护一个已兑换 token 的 hash 集合（或把 WeakMap 换成带 TTL 的 Set/Map）即可做到"成功兑换即原子消费"；再补一个轮换入口用于"换浏览器 / 首兑响应丢失"。但这会改变"同一链接多设备打开"的既有用法，建议先以 feature request 讨论默认语义（一次性 / 可选 / 短时过期）。

不等核心改动的缓解

• 泄露后重启 dsh web：新进程 = 新 token，旧链接立即失效；但注意已签发的 cookie 仍然有效。
• 要连已签发 cookie 一起撤销：轮换或删除 credentials 里的 client-connection/browser-session 记录——所有浏览器会话立刻失效，代价是需要用新链接重新登录。
• 缩短 cookieMaxAgeDays 可压缩"cookie 被复制后还能用多久"的窗口。
• 不要把 dsh web 暴露到非回环地址；必须暴露时放在自带认证的反向代理后面，并收紧 trustedHosts。

如果这个分析对你有帮助，可以标记为答案，方便后来遇到同类认证问题的用户检索。

[wuzi-spark]

我们现在是部署到云端，你说的代理方案我们考虑过，会比较复杂，需要普通 HTTP、上传下载、流式响应以及 WebSocket 都要支持，并处理响应头和连接释放。如果官方支持让token可以兑换后失效，那就太好了，我们目前不考虑多设备使用的情况，而且就算要用，也会让用户重新登录