非 localhost HTTP 访问 web GUI 时 RPC 全部失败：crypto.randomUUID is not a function

[ai2open]

通过局域网 IP 或 NAT 映射地址（如 http://192.168.x.x:3080）访问 dsh web GUI 时，浏览器端任何 RPC 都抛出 TypeError: crypto.randomUUID is not a function，设置工作区等操作无法完成。

复现、预期与验收

• 复现步骤：
  1. 以 0.0.0.0 绑定启动 web 服务（pnpm dsh --profile web --patch <overlay> --no-open）；
  2. 浏览器通过 http://<非 localhost 地址>:3080 打开页面；
  3. 打开「设置工作区」，或执行任何触发 RPC 的操作。
• 实际结果：操作失败，浏览器抛 TypeError: crypto.randomUUID is not a function。
• 预期结果：非安全来源（insecure origin）下 RPC 正常完成。
• 环境：dsh 0.1.1-rc.2（master b150a551），Node v24.15.0，Linux，现代 Chrome/Edge。
• 验收条件：http://<LAN-IP>:3080 下 workspace.list / host.listDirectory 等 unary RPC 成功；新增模拟无 crypto.randomUUID 环境的回归测试。

根因分析

• crypto.randomUUID() 仅在安全上下文（HTTPS 或 localhost）可用；普通 HTTP 的局域网地址不是安全上下文，此时 crypto.randomUUID 为 undefined。
• packages/host/apiproxy/src/fetch/client.ts 的 AbstractApiClient.mintRpcId() 直接调用 crypto.randomUUID()；浏览器端 WebApiClient（packages/client/connection/src/client/web-api-client.ts）未覆写它，unary RPC 在铸造 rpcId 时即抛错。
• 连接包已有基于 crypto.getRandomValues()（非安全来源可用）的 randomUuid()（packages/client/connection/src/client/random-uuid.ts），rpc.call 路径已使用并配有测试（client-apply.client.spec.ts 的 secure-context 用例），但 unary 路径遗漏。
• 同类隐患还有一处：packages/client/ui-conversation/src/client/service.ts:66 添加附件草稿时同样直接调用 crypto.randomUUID()。

已验证的修复方案

WebApiClient 覆写 mintRpcId() 复用 randomUuid()：

protected override mintRpcId(): RpcId {
  return RpcId(randomUuid())
}

并在 client-apply.client.spec.ts 增加回归用例（vi.stubGlobal('crypto', { getRandomValues }) 下断言 unary 调用的 rpcId 为合法 v4 UUID）。连接包 112 个测试全绿，重建后实际通过局域网 HTTP 访问验证通过。如需要，我可以整理成 PR。

另附一个部署侧观察（非 bug，供文档参考）：修复后通过 NAT 映射地址访问会命中 /api 的 DNS-rebinding 信任栅栏（全部 403），需在 patch overlay 中给 web-runtime 声明 trustedHosts: ['<映射后的 host:port>']（overlay 只接受字面值，!!js 不可用）。建议部署文档补充这一说明。

[tgeruzov]

Your diagnosis looks correct. This is caused by crypto.randomUUID() being restricted to secure contexts, so plain HTTP on a LAN IP doesn't expose it even though crypto.getRandomValues() is available.

Reusing the existing randomUuid() helper for WebApiClient.mintRpcId() is the right fix. I'd also change the draft-attachment call site for the same reason, otherwise that path can still fail on an insecure origin.

For an immediate workaround, access the UI through localhost/127.0.0.1 (for example via an SSH tunnel) or put HTTPS in front of it.

One separate issue to keep in mind: fixing the UUID generation doesn't bypass the trusted-host protection. If you're accessing it through a LAN/NAT hostname, that host still needs to be allowed by the web runtime configuration.