ririv/dsh-lan-access

README excerpt

dsh-lan-access 一个 DeepSeek Harness（DSH）Web 客户端插件：在浏览器处于 非安全上下文 （典型场景：通过明文 HTTP 访问局域网 IP，例如 http://192.168.1.20:3080 ）时，为缺失的 crypto.randomUUID() 打补丁，从而恢复 Web GUI 的完整功能。 纯客户端插件，不改动任何 DSH 核心包，随 /.dsh 配置持久化。 背景 现象 dsh web 服务启动后： - 在本机访问 http://127.0.0.1:3080 ，一切正常。 - 在同局域网其他设备访问 http:// :3080 ， 页面能打开，但功能全废 ：看不到会话、看不到工作区、选不了工作区、模型列表加载不出来。 根因 浏览器的 Web Crypto 只在 安全上下文（secure context） 里暴露 crypto.randomUUID() 。安全上下文包括 HTTPS、 localhost 、 127.0.0.1 ，但 不包括 明文 HTTP 访问局域网 IP。 DSH 的客户端连接包 @deepseek-ai/dsh-client-connection 在 mintRpcId() 里直接调用 crypto.randomUUID() 来给每个 /api RPC 请求生成关联 ID。在非安全上下文下， crypto.randomUUID 是 undefined ，于是： 1. 每个 /api unary RPC 在真正发出 fetch 之前就抛出 TypeError: crypto.randomUUID is not a function ； 2. 连接握手（ host.describe ）失败，循环进入重连； 3. 承载会话/工作区/模型列表数据的请求与 WebSocket 全部无法建立； 4. 最终表现为“静态页面能渲染（那些请求不走 RPC），但所有数据区空白”。 为什么用插件而不是改核心包 DSH 本身有 randomUuid() （基于 crypto.getRandomValues ，非安全上下文同样可用），但 mintRpcId() 没用它。改核心包需要动 /opt/homebrew/lib/node modules/... 下的文件，且升级/重装即失效。用一个客户端插件在页面启动早期补齐 crypto.randomUUID ，副作用最小、随配置持久、易于迁移。 工作原理 插件的 package.json 声明： immediately: true 让该插件进入 boot 图的“立即层”。客户端插件的 apply() （其中 client-runtime 会调用 connection.start() → mintRpcId() ）通过 cordis 的 fiber 微任务调度执行；而本插件的…

Category