[bug]标题:浏览器端 crypto.randomUUID() 在局域网 HTTP 访问下崩溃(非安全上下文),页面无法使用

[SpiritLiberationqq]

标题:浏览器端 crypto.randomUUID() 在局域网 HTTP 访问下崩溃(非安全上下文),页面无法使用

版本:@deepseek-ai/dsh 0.1.0-rc.6(web profile)

问题描述: 通过配置把 webserver 绑定到 0.0.0.0 后,手机等局域网设备用 http://:3080 访问 Web GUI,页面加载即报错 crypto.randomUUID is not a function,界面无法使用。

复现步骤:

在 ~/.dsh/profiles/web/cordis.patch.yml 中把 webserver 绑定到 0.0.0.0(webserver schema 允许该值,且 dsh-web-app 会自动将本机 LAN IP 加入 /api 信任栅栏并打印 LAN URL,说明局域网访问是官方支持的部署方式)
手机浏览器打开
http://192.168.x.x:3080/
(明文 HTTP,非 loopback)
页面加载即抛 crypto.randomUUID is not a function
根因分析: crypto.randomUUID() 是安全上下文(secure context)专属 Web API,仅在 HTTPS 或 localhost 下存在;通过明文 HTTP 访问局域网 IP 不属于安全上下文,该 API 为 undefined。相关调用点:

dsh-client-connection/lib/client.js — mintRpcId() 每条 C→S RPC 都调用 crypto.randomUUID(),页面一加载就崩
dsh-host-apiproxy/lib/types/fetch/client.js — 同上的 mintRpcId()
dsh-client-ui-conversation/lib/client.js — browserDraftAttachment() 附件草稿 ID
对比:node 端(dsh-client-connection/lib/index.js)使用 node:crypto 的 randomUUID,不受影响;CLI 拒绝 --host 0.0.0.0(dsh-web-app/lib/startup.js,安全考虑,可以理解),但配置 patch 路径是官方留出的合法通道,因此该场景应被支持。

期望行为: 局域网 HTTP 访问时浏览器端正常生成 UUID,或给出明确的不支持提示。

建议修复: crypto.getRandomValues() 在非安全上下文可用,建议在 client 端为 crypto.randomUUID 提供基于 getRandomValues 的 UUID v4 fallback(例如 if (!crypto.randomUUID) { … }),或统一封装一个 UUID 工具函数,替换三处裸调用。

临时规避(供其他用户参考): 在 dsh-web-frontend/dist/index.html 的 中、模块脚本之前注入同步 polyfill(用 crypto.getRandomValues 实现 UUID v4),可解决;升级后需重新应用。

[pengpengyi92]

感谢这份精确的复现与根因定位。我对当前 master（47f943859b）做了调用点审计：connection 自有 RPC 路径已经有 getRandomValues() helper，但共享 AbstractApiClient.mintRpcId() 与 conversation draft attachment 仍直接依赖 secure-context-only 的 crypto.randomUUID()。

我在 fork 中准备了一个有边界的补丁：

• branch: https://github.com/pengpengyi92/deepseek-harness/tree/fix/insecure-origin-uuid
• commit: pengpengyi92@16a0c0a

补丁把现有 browser-safe UUID v4 helper 移到 @deepseek-ai/dsh-host-apiproxy/api 作为共享 client contract，并覆盖报告中的 live fetch RPC、connection RPC/fixture 与 draft attachment 路径。它保留 RFC 4122 version/variant bits，仍使用 Web Crypto randomness，不退化到 Math.random()；Node-only UUID 调用不在本次范围内。

验证结果：

• focused Vitest: 3 files / 61 tests passed；新增测试会移除环境中的 randomUUID，只保留确定性的 getRandomValues()
• targeted TypeScript project build passed
• Oxlint passed
• package invariants passed（219 packages）
• client bundle purity passed（13 tests）
• pre-push full host/client typecheck and build passed
• Agent Note format / classification / translation pairing passed

当前 CONTRIBUTING.md 明确说明暂不接受 external pull requests，因此没有创建上游 PR；先把可运行 patch 和验证证据放在 fork，供 maintainer 评估或挑选。若之后开放 PR，我可以基于最新 master 重放最小变更。

[farfoodyou]

补充一个不同暴露路径的复现，确认与 0.0.0.0 绑定无关：

服务端保持 loopback 绑定，LAN 暴露走 socat 转发（未用 0.0.0.0，未改 cordis.patch.yml）：

  dsh web --port 8080 --trusted-host 10.77.14.173:8080
  socat TCP-LISTEN:8080,bind=10.77.14.173,range=10.77.51.54/32,fork,reuseaddr TCP:127.0.0.1:8080

客户端访问 http://10.77.14.173:8080/ 同样抛 crypto.randomUUID is not a function。期间 /api 信任栅栏对 --trusted-host 声明的 authority 正常放
行（200），因此是纯客户端 secure-context 问题，与 @pengpengyi92 的定位一致。+1 于共享 client contract 的 getRandomValues() 兜底方案。

这场景也不少吧? 不知道后续咋解决.

[farfoodyou]

最简单的办法还是直接ssh 把端口从A机器映射到B机器上

ssh -L 18080:127.0.0.1:8080 user@host -N

这样不用折腾, 省事, 省心, 省力.

[talaon2]

通过nginx中转也是报 randomUUID