Web UI: every POST to /api/* returns 403 Forbidden (trust fence Origin/Host port mismatch)

[Triangle-GitHub]

What happens

pnpm dsh web at http://127.0.0.1:3080, opened in Edge (Chromium 151). The page loads
and the WebSocket streams connect, but every POST to /api/* returns 403 forbidden,
breaking the whole UI (workspace creation, settings, credentials, host.describe...).

Repro

1. pnpm install && pnpm run build && pnpm dsh web
2. Open http://127.0.0.1:3080 in Edge.
3. Every POST /api/… → 403.

Cause

packages/client/connection/src/api-request-trust.ts, in isTrustedApiRequest:

return new URL(origin).host === hostUrl.host

WHATWG .host drops the default port, so a port-less Origin from the browser never
matches the Host header:

new URL('http://127.0.0.1').host      // '127.0.0.1'
new URL('http://127.0.0.1:3080').host  // '127.0.0.1:3080'

Edge sends Origin: http://127.0.0.1 (no port) on fetch(), but Host: 127.0.0.1:3080
(with port) — WebSocket handshakes keep the port, which is why only POSTs fail.

Fix

return new URL(origin).hostname === hostUrl.hostname

Verified locally: with Origin: http://127.0.0.1 + Host: 127.0.0.1:3080, requests now return 200.

[zoahdev]

Confirmed at source level and implemented as a cherry-pick-ready branch - your diagnosis is exact.

Source audit (master 47f9438)

packages/client/connection/src/api-request-trust.ts (isTrustedApiRequest) compares new URL(origin).host === hostUrl.host. WHATWG .host keeps the non-default port, so a port-less Origin never matches a ported Host - every POST 403s while the WebSocket handshakes (which keep the port) still connect.

Patch: fix/api-trust-origin-hostname-portless

https://github.com/zoahdev/deepseek-harness/tree/fix/api-trust-origin-hostname-portless

• Origin comparison now uses .hostname, mirroring the existing trustedHosts convention where a port-less authority matches any port.
• Security note kept in the code: the fence is a same-site defense, not an auth layer - local processes can already pass with Origin-less requests, and cross-hostname / opaque (null) origins stay refused.

Verification

• tsc -b tsconfig.host.json - clean
• api-request-trust 11/11, including a new Web UI: every POST to /api/* returns 403 Forbidden (trust fence Origin/Host port mismatch) #2009 regression case (port-less Origin + ported Host for loopback and declared authorities, plus a cross-hostname rejection)

Thanks for the minimal repro - this one was breaking the entire UI on a specific browser, which is the worst kind of bug to find.

[Electricitysheep]

Origin/Host 端口不匹配触发 trust fence——127.0.0.1:3080 的 origin 校验把页面请求全 403 了。和 #128/#755（局域网 403）是同一条线：trustedHosts/origin 匹配太严格。

临时：确认访问地址和 trustedHosts 完全一致（含端口）。第 12 章有记录：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/12-limitations.md

[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.

[wuyak]

Confirmed again against current upstream master / dsh-v0.1.0-rc.8 at 141eb6fef83422698aef7a981029e843e8161534. The relevant trust source and regression-test files are unchanged from 47f9438, and the current check is still:

new URL(origin).host === hostUrl.host

In the affected Chrome profile, CDP captured this actual POST shape:

Host: 127.0.0.1:3080
Origin: http://127.0.0.1
Referer: http://127.0.0.1:3080/
Sec-Fetch-Site: same-origin

The impact is broader than the directory picker: the shared /api route applies isTrustedApiRequest before RPC dispatch, so every HTTP POST RPC is rejected (host.describe, session/workspace calls, settings, credentials, model discovery, prompts, etc.). Static assets still load, which leaves a rendered frontend shell with an unusable backend. WebSocket upgrades also call the same helper, although Chromium may retain the port in WebSocket Origin; even if those downlinks connect, readiness still fails when host.describe is rejected.

I tested a narrower compatibility fallback than globally switching to hostname-only comparison. It accepts the port-less Origin only when all of these hold:

• the request Host is loopback;
• Origin and Host have the exact same hostname and Origin has no port;
• Sec-Fetch-Site is same-origin;
• Referer uses the same protocol as Origin and its authority exactly matches the Host, including the real service port.

Cross-site, opaque (Origin: null), wrong-Referer-port, and declared non-loopback authority cases remain rejected, so existing exact-port semantics are not widened for public/trusted hosts.

Verification on the rc.8 checkout:

• pnpm install --frozen-lockfile succeeded;
• pnpm run build succeeded;
• pnpm exec vitest run packages/client/connection/tests: 10 files / 111 tests passed;
• an HTTP probe using the exact captured header tuple above returned 200 after the patch.

This confirms the bug is still present in rc.8 and that one helper-level fix restores the whole HTTP RPC surface, not only host.pickDirectory.