为嵌入式/桌面集成提供本地可获取的认证途径

[hjxcloud-tech]

我是 Obsidian 社区插件 DSH for OB 的作者。该插件把 dsh web 内嵌进 Obsidian 侧边栏，本地 loopback 使用为主。

问题：DSH 0.1.2 起 dsh web 启用一次性 token + 浏览器 cookie 认证。token 只打印在启动输出里，桌面集成通常以隐藏控制台/守护进程方式拉起服务，拿不到这段输出；且认证 cookie 是 SameSite=Strict。我们在 0.1.2-rc.1 实测（隔离部署 + Obsidian 内嵌 iframe 验证）：内嵌页面无法完成 token 到 cookie 的跳转链路，这是浏览器内核安全策略，嵌入方无法绕过。结果：内嵌面板在 0.1.2+ 整体不可用。

诉求（任一即可，均不削弱现有安全，也不请求按 Host 头放宽）：

token 落盘（推荐）：
1.启动时把本次 token 写入 ~/.dsh/web-launch-token（仅当前用户可读，退出清理）。token 本就是仅本机可得的一次性凭据，能读该文件的进程本就能读 .credentials.yaml，不扩大攻击面。
2. --auth 分级：默认保持现状；lan 档请基于 socket 实际来源地址判定回环，不要基于 Host 头（避免 #130 的伪造路径）。
或环境变量显式关闭（本机场景自担风险，文档注明）。

[argszero]

源级核实完成（master d347e70390）——你的机制描述准确，且三个诉求的安全权衡各自成立。但有一个关键区分值得先说清：token 落盘修的是"拿不到 token"，它并不解除 iframe 的 cookie 墙——对 OB 内嵌场景真正可行的是 ②/③（或一个不经 cookie 的 embedder 模式）。

源码确认：

• launch token = 每进程随机（browser-auth.ts PROCESS_LAUNCH_TOKENS WeakMap），只经 console.log 输出（bundle/web-app/src/index.ts:280）+ 自动开浏览器（:284）——隐藏控制台/守护进程确实拿不到。
• cookie：SameSite=Strict + HttpOnly（browser-auth.ts:122），名字与签名 audience 都绑定 Host header 的 authority（requestAuthority :69-74、cookieName :106），非 socket 源地址。
• 交换链：GET /?token=X（单 token、pathname /）→ mint cookie → 302 到干净的 /（:243-261）；之后全靠 cookie。

token 落盘（你的方案 1）评估：攻击面论证成立——browser-session 的签名 secret 本就持久化在 credentials store（initializeSecret → credential record），把 launch token 写 ~/.dsh/web-launch-token（0600、退出清理或短 TTL）不跨新信任边界，且修好 tray/启动器类集成（它们能开真实浏览器、能持 cookie，只差 token 构造 URL）。这是干净的小 diff（web-app 装配面，core → upstream-fix 候选）。

但 iframe 场景的关键：SameSite=Strict cookie 在跨站 iframe 里既设不上也发不出——Obsidian 顶层 origin ≠ 127.0.0.1 时，iframe 内 dsh 页面对 127.0.0.1 的请求其 site-for-cookies 是顶层站（跨站）→ Strict cookie 不附带；而 http://127.0.0.1 无法用 SameSite=None（需 Secure）。所以即使嵌入方拿到 token 并完成首次交换，302 后的干净 / follow-up 仍 401——链条在 iframe 内结构性无法闭合，这正是你说的浏览器内核策略。token 落盘不改变这一点。

因此对 OB 内嵌，可行形状是：② socket 源地址判定 + 显式信任档（方向与既有 trust-fence 家族结论一致——Host 头可被反代伪造，socket 来源才是 loopback 的可信判据；本仓已有 sibling 讨论 #5835 同为此 local-first 启动姿态的摩擦面）；③ env 显式关（文档注明自担风险）；或 ③b：显式 embedder 模式——每请求携带 launch token（Authorization: Bearer 或 query），不经 cookie，仅 loopback + 显式开启时接受，保留现有默认与一次性语义。③b 对"内嵌面板"是侵入最小的：无 cookie、无跳转、每请求认证，Obsidian 侧只需持有 token。

修复面在 core（web profile 装配 + browser-auth），非插件可挂载层 → upstream-fix 候选；社区侧 today-workaround 有限（顶层窗口交换后 iframe 仍不带 Strict cookie），所以这个值得开成正式设计讨论。若你愿意，可以把 ③b 的具体握手（token 生命周期/刷新/登出）细化成提案，我帮你对照 browser-auth 的 audit 与 fencing 约束走查。

[hjxcloud-tech]

【设计提案】Embedder 认证模式：per-request launch token，不经 cookie（方案③b）

代码锚点均已按 master commit d347e70 源级核对，文件与行号可直接对照。

一、背景与定位

承接讨论帖「为嵌入式集成提供本地可获取的认证凭证途径」。0.1.2+ 的浏览器会话认证（browser-auth.ts）在 Obsidian 等内嵌宿主中结构性不可用：SameSite=Strict cookie 在跨站 iframe 既设不上也发不出，而 http://127.0.0.1/ 无法满足 SameSite=None 的 Secure 前提；即使嵌入方拿到 token 并完成 token→303→cookie 交换，303 后的干净 / 仍 401，链条无法在 iframe 内闭合（隔离部署 0.1.2-rc.1 + Obsidian 内嵌实测确认）。

二、握手规范

启用：dsh web 新增显式开关 --embed-token（默认关闭；关闭时现有 303+cookie 行为逐字节不变，两条路可并存——同一进程内真实浏览器仍可走 cookie 交换，内嵌页面走 per-request token，互不影响）。

凭据：复用现有每进程 launch token（browser-auth.ts L20 PROCESS_LAUNCH_TOKENS WeakMap，进程生命周期随机值），不引入新密钥、不改其生成与轮转语义。

校验顺序（安全不变量）：

1. 先过既有 Host/Origin trust fence（api-request-trust，与 安全建议：在远程认证完善前，不建议绕过 dsh web 的非 loopback 暴露限制 #130 结论一致，DNS rebinding 在此被拦）；
2. fence 通过后，凭证接受优先级：Authorization: Bearer > ?token= 查询参数 > 现有 cookie 会话；
3. token 比较沿用现有常数时间实现（tokenMatches）；
4. embed 模式不发 cookie、不建会话，纯 per-request 无状态；
5. 失败返回与现状一致的 401，审计日志不记录 token 值（仅记录模式与是否命中）。

Index 语义：embed 模式且凭证有效时，GET / 带不带 token 查询参数均可直接 200 服务 index（跳过 303+Set-Cookie 分支）；后续 /api 事件与调用流量由嵌入方携带凭证（见第四节）。

生命周期：token 与进程同生死，重启即轮转，无显式登出端点（与现状一致）。

三、服务端改动点

1. packages/client/connection/src/browser-auth.ts
   新增 authenticateRequest(req)：读 Authorization 头 Bearer 值，缺省回落查询参数 token；命中进程 launch token 即通过。
   authorizeIndex（L240）：embed 模式启用且 authenticateRequest 通过时直接返回 true（放行 200），不进 303/cookie 分支。
2. packages/client/connection/src/rpc-host.ts
   requestRejection（L97-99）：isAuthenticated（cookie）失败后、返回 401 前，追加 embed-token 接受路径。
   所有经 register() 注册的 /api 路由（含事件通道，见 L169 route handler 前守卫）自动获得同一保护，单点改动全覆盖。
3. packages/client/connection/src/index.ts（L112 BrowserAuth.create 装配处）：传入 embedToken 配置位。
4. packages/bundle/web-app/src/startup.ts（L51-54 选项区）：新增 .option('--embed-token', 'accept per-request launch-token auth for embedded hosts; default off')；
   packages/bundle/web-app/src/index.ts（L271-283 authenticatedUrl 计算与打印处）：开关生效时在打印行尾追加 embed-token mode active，便于集成方自检。
5. 测试矩阵：Bearer 命中 / query 命中 / 两者皆坏仍 401 / 开关关闭时行为逐字节回归 / fence 先于 token 的 rebinding 用例。

四、嵌入方集成（零 DSH 前端改动）

浏览器 API 不允许给 WebSocket 握手加 header，故 query 形态保留为 WS 兜底；HTTP 侧优先 Bearer。嵌入方在其注入面完成凭证附加——以 dsh-harness 为例（已有 webServer.tapIndex 注入能力）：

const T = '本次进程 launch token'
const nativeFetch = window.fetch.bind(window)
window.fetch = (input, init) => nativeFetch(input, Object.assign({}, init, { headers: Object.assign({}, (init || {}).headers, { authorization: 'Bearer ' + T }) }))
const NativeWS = window.WebSocket
window.WebSocket = function (url, protocols) { return new NativeWS(url + (String(url).includes('?') ? '&' : '?') + 'token=' + T, protocols) }

iframe 首载 GET /?token=T 得 200，页面内全部 API/事件流量自动带凭证。无注入面的宿主亦可反向代理补头，不改 DSH 前端一行代码。

五、安全分析（对照既有 fencing/audit 约束）

DNS rebinding：fence 在校验顺序第一步，attacker.com 解析到 127.0.0.1 时 Host/Origin 已 403，与 token 形态无关。
token 泄露面：token 本就在本机 stdout 打印（同信任域），本提案未新增暴露渠道；Bearer 优先避免进 URL/访问日志；query 仅 WS 场景使用。
跨站页面偷发：第三方页面对 /api 的匿名 POST 本就受 fence+凭证双重限制；无凭证请求行为与现状完全一致。
默认姿态：不改默认、不放宽任何一档现有校验；关闭开关时逐字节等价现状（回归测试保障）。
审计：仅记录「embed-token 模式启用中/单次校验命中与否」，不落 token 值。