Bug: HTTP 403 on all /api requests in Chrome 150+ (port-less Origin vs host comparison)

[LiuJunheng]

Bug: HTTP 403 on ALL /api requests in Chrome 150+ (port-less Origin vs. host comparison)

Affected version: @deepseek-ai/dsh-client-connection 0.1.0-rc.7 (verified from the published npm tarball on 2026-08-18) — the issue is still present in the latest release.

Symptom

When the WebUI is opened in Chrome 150 or newer (this is the version where the behavior changed), every /api/* request from the page returns HTTP 403 — including basic ones like host.describe, session.list, and llm.discoverModels, not just privileged methods. The UI shows:

transport failure for /api/host.pickDirectory: HTTP 403

This happens in loopback mode (127.0.0.1:<port>) too, not only in LAN mode. Firefox/Edge and curl do not reproduce it, which makes it easy to dismiss as an environment problem.

Root cause

Chrome 150 changed Origin serialization for loopback URLs: for a page served from http://127.0.0.1:3080, same-origin fetch requests now send the Origin header without the port:

host = 127.0.0.1:3080
origin = http://127.0.0.1          <- port stripped by Chrome 150+
sec-fetch-site = same-origin

The trust check in dsh-client-connection/lib/index.js compares the Origin against the Host including the port:

function isTrustedApiRequest(request, trustedHosts) {
  ...
  const origin = header(request.headers, "origin");
  if (origin === void 0) return true;
  // current code (rc.7):
  return new URL(origin).host === hostUrl.host;   // "127.0.0.1" !== "127.0.0.1:3080" -> false
}

Because new URL("http://127.0.0.1").host is "127.0.0.1" but hostUrl.host is "127.0.0.1:3080", the comparison returns false and all /api requests are rejected. curl reproduces nothing because it sends the Origin with the port manually.

Suggested fix

Compare hostnames only, ignoring the port. The port is not a CSRF / DNS-rebinding boundary: a cross-site attacker's page has a different hostname, and DNS rebinding changes the Host-header hostname; the first gate (Host must be loopback or trusted) plus the sec-fetch-site: cross-site rejection already cover both. Dropping the port from the comparison does not weaken security.

// recommended:
return new URL(origin).hostname === hostUrl.hostname;

Suggested scope of the change (all 4 rejection points currently use the same isTrustedApiRequest helper, so a single fix covers them):

• fetchHandler route check
• register interceptor check
• WebSocket route check
• loopback interceptor check

Additional suggestion (LAN mode)

While touching this file, consider also honoring the LAN addresses computed by dsh-web-app (webRuntime.lanAddresses) when trustedHosts is empty and the server binds 0.0.0.0. Today dsh-client-connection pins privileged methods to loopback with an empty trustedHosts list, so LAN mode serves the page but every /api call is 403 — the two plugins' trust semantics disagree. Details in the same file around apply().

Verification of the fix

After switching to hostname comparison: host.describe / session.list / llm.discoverModels return 200 in Chrome 150+; a forged cross-site Origin (evil.example.com) is still rejected (CSRF preserved); a forged LAN IP is still rejected.

Thanks for the great project — this was the only blocker for a "double-click to run" green distribution I maintain.

---

This report was drafted with AI assistance (analysis of the root cause and the fix suggestion were verified against the published npm tarball).

[LiuJunheng]

中文版说明 (Chinese version of the issue description)

受影响版本：@deepseek-ai/dsh-client-connection 0.1.0-rc.7（2026-08-18 从 npm 官方 tarball 核对，最新版仍存在此问题）。

现象

Chrome 150 及以上版本打开 WebUI 后，页面发出的所有 /api/* 请求都会返回 HTTP 403——不只是 host.pickDirectory 等特权接口，连 host.describe、session.list、llm.discoverModels 这类普通接口也全部 403。界面报错形如：

transport failure for /api/host.pickDirectory: HTTP 403

本机模式（127.0.0.1:<端口>）同样触发，并非只有局域网模式才有。Firefox / Edge / curl 都无法复现，容易让人误以为是环境问题。

根因

Chrome 150 改变了 loopback 地址的 Origin 序列化行为：页面地址为 http://127.0.0.1:3080 时，同源 fetch 请求发出的 Origin 头不带端口：

host = 127.0.0.1:3080
origin = http://127.0.0.1        <- Chrome 150+ 剥离了端口
sec-fetch-site = same-origin

而 dsh-client-connection/lib/index.js 的信任校验把 Origin 与 Host 按端口精确比较：

function isTrustedApiRequest(request, trustedHosts) {
  ...
  const origin = header(request.headers, "origin");
  if (origin === void 0) return true;
  // 当前代码 (rc.7):
  return new URL(origin).host === hostUrl.host;   // "127.0.0.1" !== "127.0.0.1:3080" -> false
}

new URL("http://127.0.0.1").host 得到 "127.0.0.1"，而 hostUrl.host 是 "127.0.0.1:3080"，比较结果为 false，于是所有 /api 请求被拒绝。curl 复现不出来，是因为它手动带了端口。

建议修复方案

只比较 hostname，忽略端口。端口不是 CSRF / DNS-rebinding 的安全边界：跨站攻击者页面是不同的 hostname，DNS rebinding 改变的是 Host 头里的 hostname——第一道"Host 必须为 loopback 或受信任"的校验加上 sec-fetch-site: cross-site 拒绝已经覆盖了这两种攻击。忽略端口不会削弱安全防护。

// 推荐写法:
return new URL(origin).hostname === hostUrl.hostname;

建议修改范围（4 个拒绝点都复用同一个 isTrustedApiRequest 工具函数，改一处即可全部覆盖）：

• fetchHandler 路由校验
• register 拦截器校验
• WebSocket 路由校验
• loopback 拦截器校验

附带建议（局域网模式）

顺手处理同一文件中的另一处问题：当服务以 0.0.0.0 绑定、且 trustedHosts 为空时，dsh-web-app 算出的本机局域网地址（webRuntime.lanAddresses）并未被 client-connection 采纳——特权接口被 pin 死在 loopback，导致"页面能开但所有 /api 都 403"。建议在 apply() 里把 webRuntime.lanAddresses 并入 trustedHosts，让两个插件的信任语义一致。

修复验证

改用 hostname 比较后：Chrome 150+ 下 host.describe / session.list / llm.discoverModels 全部恢复 200；伪造跨站 Origin（evil.example.com）仍被拒绝（CSRF 保留）；伪造局域网 IP 仍被拒绝。

感谢这个优秀的项目——这是我维护的"双击即用"绿色分发版唯一被卡住的问题。

---

本报告由 AI 辅助撰写（根因分析与修复建议已对照 npm 官方 tarball 核实）。

[LiuJunheng]

Update: a green "double-click to run" distribution already fixes this (中文/English)

我们维护的绿色整合版启动器已经解决了这个问题，欢迎参考或直接使用（附上我们的方案与仓库地址）。

We maintain a green "double-click to run" launcher distribution that already fixes this issue. Feel free to reference the approach or use the release directly. Repos and solution below.

---

解决方案 (How we fixed it)

启动器在安装/启动 dsh 时，会对 @deepseek-ai/dsh-client-connection/lib/index.js 自动打一个幂等补丁（dsh 升级重装后会自动重打，补丁分两段，任一段官方已修复则自动跳过，绝不误伤）：

The launcher applies an idempotent patch to @deepseek-ai/dsh-client-connection/lib/index.js on every dsh install/start (it is re-applied automatically after a dsh upgrade; the patch is split into two parts and each part is skipped once upstream fixes it, so it never breaks anything):

段 1 · Chrome 150 无端口 Origin（本贴主问题） / Part 1 · port-less Origin (the issue in this thread)：

// 官方 rc.7 现状 / upstream rc.7:
return new URL(origin).host === hostUrl.host;      // "127.0.0.1" !== "127.0.0.1:3080" -> 403

// 我们的补丁 / our patch:
return new URL(origin).hostname === hostUrl.hostname;  // 忽略端口, Chrome 150+ 恢复 200

段 2 · 局域网模式 trustedHosts / Part 2 · LAN mode trustedHosts：未显式配置 trustedHosts 且以 0.0.0.0 绑定时，自动把 dsh-web-app 提供的本机局域网地址（webRuntime.lanAddresses）并入信任列表，特权接口不再被 pin 死在 loopback；同时给所有 403 出口加诊断日志（记录 url/method/ua/host/origin/sec-fetch-site），排查此类问题一眼可见。

When binding 0.0.0.0 with an empty trustedHosts, we merge the machine's LAN IPs from dsh-web-app (webRuntime.lanAddresses) into the trusted list so privileged APIs are no longer pinned to loopback; we also added diagnostic logging at every 403 exit (url/method/ua/host/origin/sec-fetch-site) to make such issues visible at a glance.

验证 / Verified：Chrome 150+ 下 host.describe / session.list / llm.discoverModels 全部 200；伪造跨站 Origin 与伪造局域网 IP 仍 403（安全边界保留）。

---

绿色版仓库地址 (Repositories)

平台	仓库	Release 下载
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

绿色整合版特点：双击即用、所有运行时依赖（便携 Node / 内置 Python / dsh 本体）全部本地化在程序目录、不写用户主目录、不占 C 盘、整目录拷贝即用；对外围文件更新走绿色版自身的 Release（GitHub 连不通自动转 Gitee 发布版附件直连下载）。

The green edition is double-click-to-run with all runtimes (portable Node / bundled Python / dsh itself) localised inside the program directory — no writes to the user profile, no C-drive footprint, copy-and-run. Its own green-version updater falls back from GitHub to Gitee release attachments when GitHub is unreachable.

欢迎直接下载使用；如果本贴的修复被官方采纳，我们的补丁会自动停用对应段落。

Feel free to try it out. If upstream adopts a fix, our patch will automatically retire that part.

---

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