BUG: Web GUI via http://127.0.0.1:3080 — every /api call returns 403 (Chrome Origin header omits the port)

[fhghth]

Web GUI: every /api call returns 403 when opened via http://127.0.0.1:3080 (works via localhost)

环境 / Environment

• dsh: 0.1.0-rc.6 (global npm install, web profile)
• OS: Windows 11 (x64)
• Browser: Google Chrome 151.0.7922.138 (Windows)
• Reproduced with: dsh web (default 127.0.0.1:3080), fresh install/start

现象 / Symptom

Open the Web GUI at http://127.0.0.1:3080/ in Chrome: the page loads, but every /api/* RPC fails with HTTP 403, e.g. the GUI shows transport failure for /api/llm.providers: HTTP 403 (also host.describe, settings.describe, …). The same GUI opened at http://localhost:3080/ works fine (all requests return 200).

请求头抓包 / Captured request (DevTools, failing request)

POST /api/host.describe HTTP/1.1
Host: 127.0.0.1:3080
Origin: http://127.0.0.1        <-- NOTE: port is MISSING
Referer: http://127.0.0.1:3080/
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
content-type: application/json
User-Agent: Mozilla/5.0 ... Chrome/151.0.0.0 Safari/537.36

The Sec-Fetch-Site: same-origin + Referer prove the request is genuinely same-origin; only the Origin serialization differs.

根因 / Root cause

packages/client/connection (built: lib/index.js, source likely src/types/api-request-trust.ts), isTrustedApiRequest() ends with a strict host:port equality between the Origin header and the Host header:

const origin = header(request.headers, "origin");
if (origin === void 0) return true;
try {
    return new URL(origin).host === hostUrl.host;   // "127.0.0.1" !== "127.0.0.1:3080" → false → 403
} catch {
    return false;
}

Recent Chrome versions serialize the Origin header without the port when the initiator origin's host is an IP literal such as 127.0.0.1 (known behavior change; e.g. https://stackoverflow.com/questions/79625700/chrome-sending-wrong-origin-header-on-127-0-0-1, and other projects had to adapt, e.g. onyx-dot-app/onyx#9382 "ignore port when determining origin in dev"). localhost is not affected (the port is still serialized), which explains the asymmetry.

Verified server-side against a live dsh web instance with the exact captured headers:

Origin header	Host header	Result
http://127.0.0.1 (no port)	127.0.0.1:3080	403
http://127.0.0.1:3080	127.0.0.1:3080	200
http://localhost:3080	localhost:3080	200

Impact: every /api/* route (HTTP bridge + the shared-channel interceptor + the WebSocket downlink gate all call the same isTrustedApiRequest), so the whole GUI is broken on 127.0.0.1 for affected Chrome versions.

建议修复 / Suggested fix

Tolerate a port-less Origin header while keeping the protection: require the hostname to match, and only require the port to match when the Origin header actually carries one (the request's authority/port remains enforced via the already-validated Host header):

const origin = header(request.headers, "origin");
if (origin === void 0) return true;
try {
    const originUrl = new URL(origin);
    if (originUrl.hostname !== hostUrl.hostname) return false;
    return originUrl.port === "" || originUrl.port === hostUrl.port;
} catch {
    return false;
}

This keeps the DNS-rebinding / cross-site defense (non-loopback or untrusted Host is still rejected earlier; a mismatched hostname or an explicit mismatched port is still rejected) while no longer false-positiving on Chrome's port-less Origin serialization.

备注 / Note

• The node:http bridge constructs the fetch Request with a fake authority (http://dsh.internal), so the fix should keep comparing against the Host header (the wire authority) rather than request.url.
• Workaround for users: open the GUI via http://localhost:3080 instead of http://127.0.0.1:3080 (identical server/session).

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