[BUG] /api trust fence rejects Chromium port-less Origin: 403 blocks workspace directory picker (host.pickDirectory)

[BohnChen]

发现BUG后，deepseek v4 Flash 帮我修复了该 bug，并提交了如下讨论，正文内容为 AI 书写，它已将我本地代码修复了。报错截图如下：

大家好，我在当前 master（0.1.0-rc.5，commit 47f943859b）的 Web UI 上遇到了一个可稳定复现的 403。按贡献指引发到这里（目前仓库暂不接受外部 PR）。

环境

• 机型：Apple Silicon MacBook Pro（Mac16,5），macOS 26.6.1（Build 25G76）
• 浏览器：Chrome 151.0.7922.137（Chromium），默认设置
• 运行时：Node v26.7.0、pnpm 11.7.0
• dsh：源码构建（pnpm run build）后以 pnpm dsh web 启动

复现步骤

1. 设置 DEEPSEEK_API_KEY 后运行 pnpm dsh web
2. 在 Chrome 打开 http://127.0.0.1:3080
3. 点击「添加工作区」→ 系统文件夹选择流程失败，弹出「无法打开文件夹」并显示 transport failure for /api/host.pickDirectory: HTTP 403；点「重新选择」每次都复现

因此 Chrome 下完全无法创建工作区。同源 curl（带 Origin: http://127.0.0.1:3080）请求正常，掩盖了非浏览器客户端不会遇到该问题的事实。

诊断

/api 浏览器信任栅栏 isTrustedApiRequest（packages/client/connection/src/api-request-trust.ts）要求附加的 Origin 与 Host 权威完全一致（new URL(origin).host === hostUrl.host）。

通过临时在服务端加日志，实测 Chrome 请求头为：

• Host: 127.0.0.1:3080
• Origin: http://127.0.0.1 —— Chromium 剥掉了端口
• Sec-Fetch-Site: same-origin、Sec-Fetch-Mode: cors、Referer: http://127.0.0.1:3080/

于是 new URL('http://127.0.0.1').host = 127.0.0.1 ≠ 127.0.0.1:3080 → 在任何 RPC 分发之前返回 403。根因：Chromium 对回环/IP 来源的 Origin 头序列化时不带端口（Chrome 151 实测）；因此按完整权威比较会拒绝所有发往 Web UI 的合法 Chromium 请求。

解决思路（已本地实现并测试）

Origin 的主机名与 Host 主机名精确比较；仅当 Origin 携带显式非默认端口时才比较端口：

• 无端口的 Origin（Chromium 的序列化方式）接受——浏览器根本没有发送端口可供比较。
• 带端口的 Origin 必须与 Host 端口一致，从而为序列化完整来源的浏览器（如 Safari/Firefox）保留同主机跨端口 CSRF 防御。
• 两侧默认端口（:80/:443）归一化为无端口。
• 不变的部分：跨主机（攻击者主机名）仍拒绝、sec-fetch-site: cross-site 仍拒绝、Host 栅栏与 trustedHosts 语义不变；栅栏仍只是可达性策略，不是认证。

需要说明的一个边界：在 Chromium 上，同一回环主机上不同端口的请求与同源请求无法区分，因为 Chromium 会完全省略 Origin 里的端口——这是浏览器序列化的限制，不是栅栏能补的。

测试覆盖：无端口接受、带端口匹配、跨端口拒绝、https: 默认端口归一化。如有需要可提供完整 diff。

[LiuJunheng]

Hi, we hit exactly the same issue: Chrome/Chromium strips the port from the Origin header for loopback URLs (http://127.0.0.1), while the trust fence in dsh-client-connection compares new URL(origin).host === hostUrl.host including the port, so every /api/* request returns 403.

We filed a bug report with the root cause and a suggested fix (compare hostname only, ignore the port):
Bug report: #3106

We also maintain a green "double-click to run" launcher distribution that already fixes this with an idempotent patch (Origin check changed to hostname comparison; in LAN mode it also merges the machine's LAN IPs into trustedHosts). Feel free to reference the approach or use it directly:

• GitHub: https://github.com/LiuJunheng/DeepSeekHarnessGreen (releases: https://github.com/LiuJunheng/DeepSeekHarnessGreen/releases/latest)
• Gitee mirror: https://gitee.com/liujunheng/DeepSeekHarnessGreen (releases: https://gitee.com/liujunheng/DeepSeekHarnessGreen/releases)

你好，我们遇到了完全一样的问题：Chrome/Chromium 对回环地址（http://127.0.0.1）会剥离 Origin 头的端口，而 dsh-client-connection 的信任围栏用 new URL(origin).host === hostUrl.host 按含端口的 host 精确比较，导致所有 /api/* 请求 403。已向官方提交 BUG 反馈（含根因与建议修复：只比较 hostname、忽略端口）：
BUG 反馈帖：#3106

同时我们维护的绿色整合版启动器已经解决该问题（自动打幂等补丁：Origin 校验改 hostname 比较，局域网模式自动并入本机局域网 IP），欢迎参考方案或直接使用：

• GitHub：https://github.com/LiuJunheng/DeepSeekHarnessGreen（下载：https://github.com/LiuJunheng/DeepSeekHarnessGreen/releases/latest）
• Gitee 国内镜像：https://gitee.com/liujunheng/DeepSeekHarnessGreen（下载：https://gitee.com/liujunheng/DeepSeekHarnessGreen/releases）

---

本回复由 AI 辅助撰写 / This reply was drafted with AI assistance.