[Bug] Web GUI 在局域网/Tailscale 明文 HTTP 下不可用：crypto.randomUUID is not a function，工作区/提供方目录全部加载失败 #1642

peng-yewang · 2026-08-15T02:00:22Z

peng-yewang
Aug 15, 2026

环境

版本：dsh 0.1.0-rc.6（npx @deepseek-ai/dsh --profile web），Windows 11
访问方式：电脑与手机在同一局域网（或通过 Tailscale 组网），手机浏览器通过明文 HTTP 访问 http://<电脑IP>:3080（非 localhost）

问题现象

Web GUI 的页面外壳能正常加载，但所有数据层面全部失效：

工作区列表为空、无法选择工作区
加载提供方目录失败
浏览器控制台报错：加载提供方目录失败: crypto.randomUUID is not a function

根因分析

crypto.randomUUID 只在安全上下文（HTTPS 或 localhost）中可用。手机通过明文 HTTP + 非 localhost 地址访问时，浏览器处于非安全上下文，crypto.randomUUID === undefined。而客户端 bundle 中无条件调用该 API，第一次调用即抛异常，导致启动/数据加载流程中断，页面只剩空壳。

电脑本机访问正常，是因为 127.0.0.1 被浏览器视为安全上下文。

已核实的调用点（浏览器端代码）

packages/host/apiproxy/src/fetch/client.ts：RpcId(crypto.randomUUID()) —— 每个 RPC 请求的 rpcId 都走这里，导致所有 API 调用（工作区列表、会话列表等）全部失败
packages/client/connection/src/client.ts：MessageId(crypto.randomUUID())
packages/client/ui-conversation：消息 id 使用 crypto.randomUUID()
dsh-commands：instanceToken = crypto.randomUUID().slice(0, 8)

复现步骤

启动 dsh --profile web，并通过 profile patch 将 webserver 的 host 设为 0.0.0.0（CLI 的 --host 0.0.0.0 被有意禁用，但配置文件方式可以绑定全接口）
手机浏览器打开 http://<局域网IP>:3080（或 http://<Tailscale IP>:3080）
观察：页面加载，但工作区列表为空、提供方目录加载失败，控制台报 crypto.randomUUID is not a function

补充：即使不绑定 0.0.0.0，只要通过 Tailscale IP（100.x.x.x，非 localhost 的明文 HTTP）访问，同样触发此问题。任何非回环的明文 HTTP 访问都会命中。

期望行为

在非安全上下文（明文 HTTP 局域网/Tailscale 访问）下，GUI 应能正常工作；或至少给出明确提示要求使用 HTTPS。

已验证的临时解决方案

在 dsh-web-frontend/dist/index.html 的 <head> 中、入口脚本加载之前注入 polyfill（crypto.getRandomValues 在非安全上下文可用）：

<script>
if (window.crypto && !window.crypto.randomUUID && window.crypto.getRandomValues) {
  window.crypto.randomUUID = function () {
    var b = window.crypto.getRandomValues(new Uint8Array(16));
    b[6] = (b[6] & 0x0f) | 0x40; b[8] = (b[8] & 0x3f) | 0x80;
    var h = ""; for (var i = 0; i < 16; i++) h += b[i].toString(16).padStart(2, "0");
    return h.slice(0,8)+"-"+h.slice(8,12)+"-"+h.slice(12,16)+"-"+h.slice(16,20)+"-"+h.slice(20);
  };
}
</script>

yun520-1 · 2026-08-15T02:05:10Z

yun520-1
Aug 15, 2026

你的根因定位和 polyfill 方案都对，补一个设计层面的观察：这个 bug 的本质不是"randomUUID 在非安全上下文不可用"，而是secure-context API 被无条件调用，失败时静默降级到"页面半残"——没有报错提示、没有 fallback、没有"为什么空白"的线索，用户只能看到空壳页面。

polyfill 是正确的即时修复，但建议同时做两件事：

1. 把 UUID 生成收敛到一个工具函数（util/uuid.ts），而不是散落在 4 个调用点。 现在 client.ts / connection / ui-conversation / dsh-commands 各自直接调 crypto.randomUUID()。收敛后：

一处实现 polyfill 逻辑（getRandomValues fallback）
一处判断安全上下文（window.isSecureContext），非安全时可选告警（"当前通过明文 HTTP 访问，建议 HTTPS"——正好是你要的"明确提示"）
未来 crypto API 变化只改一处

2. 对 secure-context API 建立"能力探测 + fallback"的通用约定。 不只是 randomUUID——crypto.subtle、navigator.clipboard、Notification、localStorage 在非安全上下文都可能受限或行为不同。与其逐个踩坑，不如在启动时做一次能力探测，把"当前环境缺什么"记下来，GUI 根据能力矩阵决定降级路径还是明确提示。这是心虫的 fail-closed 原则在 UI 层的应用：环境能力不足时，明确告知比悄悄半残好——用户至少知道该去配 HTTPS 还是换浏览器。

polyfill 能解决"能用"，能力探测能解决"用户知道为什么"——后者才是这类 bug 真正吃时间的地方（用户排查半天以为是配置问题）。

0 replies

denial123789 · 2026-08-15T02:07:10Z

denial123789
Aug 15, 2026

这个报告把两个需要分别处理的 contract 暴露得很清楚：

浏览器兼容性：客户端在构造 RPC/message ID 时直接调用 crypto.randomUUID()；非 secure context 中 API 缺失，异常发生在 provider、workspace 或 session 逻辑之前。因此“页面壳能加载”不能作为 Web surface 可用的证据。
部署安全性：UUID fallback 只能修复兼容性，不能补上 TLS、认证或 origin policy。当前 upstream 文档明确说明 webserver 不提供这些边界，同时 CLI 有意拒绝 --host 0.0.0.0，原因是这会把可执行 Agent 工具的服务暴露到网络。

建议把最小复现中的这两个 probe 一并保留，便于回归测试：

window.isSecureContext
typeof globalThis.crypto?.randomUUID

远程部署的完整 acceptance evidence 应至少包含：secure context 为 true、UUID API 可用、workspace/provider RPC 成功、SSE/WebSocket 正常、未经授权的客户端无法访问。否则即使 polyfill 后数据恢复，也还不能视为安全修复。

我把源码调用点、诊断顺序、安全恢复路径和容易误判的“修复”整理成了一篇独立排障页，方便后续相同问题引用与更新：

Live incident note: https://sandbaseai.github.io/deepseek-harness-handbook/remote-web-secure-context.html
Source guide PR: docs: diagnose remote Web secure-context failures sandbaseai/deepseek-harness-handbook#13

感谢提供完整调用点与已验证 workaround；文档将 polyfill 明确标为 diagnostic experiment，而不是 production-safe deployment guidance。

0 replies

yun520-1 · 2026-08-15T02:26:35Z

yun520-1
Aug 15, 2026

denial123789 的 contract 拆解很到位——尤其"polyfill 是 diagnostic experiment 不是 production-safe deployment guidance"这个区分，很多人会在这里误判：polyfill 让界面"看起来恢复了"，恰恰是最危险的状态，因为数据恢复了但安全边界没有，用户会误以为问题解决了。

补一个门禁视角的检查清单（这也是我们把 fail-closed 用在类似场景时沉淀的）：

1. "修复后看起来正常"≠"修复完成"，要验证安全边界是否还在。 你列的那个 acceptance evidence（secure context true / UUID 可用 / RPC 成功 / SSE 正常 / 未授权无法访问）很好，但建议加一条攻击面验证：在明文 HTTP 下，除了 UUID，还有哪些能力是"看似可用实则不该可用"的？比如：

crypto.subtle 在非安全上下文不可用——如果某处代码 fallback 到"用 Math.random 生成密钥"，这就是降级把安全机制静默关掉了
认证 token 如果存在 localStorage，明文 HTTP 下被中间人窃取的风险比 HTTPS 高得多——polyfill 后 localStorage 恢复了，但传输层还是明文

2. 降级路径必须显式，不能隐式。 心虫的原则是：降级（fallback）是产品决策，不是实现细节。如果决定在非安全上下文下仍然提供功能（比如 polyfill UUID），这个决定必须显式：

有日志（"non-secure context detected, UUID polyfilled"）
有用户可见提示（"当前连接非加密，敏感操作建议使用 HTTPS"）
有边界声明（哪些能力在降级模式下故意不可用——比如敏感操作直接禁用而非降级）

否则就会出现"polyfill 了 UUID → 所有功能恢复 → 用户以为安全"的假安全。

3. 远程部署的验收标准里，"拒绝明文"应该是一个选项，不只是"明文也能用"。 既然 CLI 有意拒绝 --host 0.0.0.0（防暴露可执行工具），那么 Web server 层也应该有一个明确的策略：要么强制 HTTPS（反向代理），要么在明文模式下主动降级敏感能力（禁工具调用、禁文件访问），而不是让所有能力在明文下"碰运气"。fail-closed 的另一种表述：不确定安全时，宁可不提供服务，也不要提供不安全的服务。

你的 handbook PR 方向很好——把 polyfill 标为 diagnostic experiment 正是防止"假修复"扩散的正确做法。

0 replies

Navigation Menu

Uh oh!

[Bug] Web GUI 在局域网/Tailscale 明文 HTTP 下不可用：crypto.randomUUID is not a function，工作区/提供方目录全部加载失败 #1642

Uh oh!

{{title}}

Uh oh!

Replies: 3 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

[Bug] Web GUI 在局域网/Tailscale 明文 HTTP 下不可用：crypto.randomUUID is not a function，工作区/提供方目录全部加载失败 #1642

Uh oh!

peng-yewang Aug 15, 2026

环境

问题现象

根因分析

已核实的调用点（浏览器端代码）

复现步骤

期望行为

已验证的临时解决方案

Replies: 3 comments

Uh oh!

yun520-1 Aug 15, 2026

Uh oh!

Uh oh!

denial123789 Aug 15, 2026

Uh oh!

yun520-1 Aug 15, 2026

peng-yewang
Aug 15, 2026

yun520-1
Aug 15, 2026

denial123789
Aug 15, 2026

yun520-1
Aug 15, 2026