iframe 嵌入 DSH 主页三重拦截坑（代理 + 本地 HTTP 双服务解法）
直播台左栏要 iframe 嵌入真实 DSH 多项目工作台，连续踩三个拦截：BrowserAuth 401（X-Frame-Options 双保险）、file:// 页面加载 http 被 Chrome 安全策略拦（ERR_CONNECTION_REFUSED）、代理不转发 WebSocket/静态资源（502）。最终用 8091 cookie 代理 + 8092 本地 HTTP 服务双服务解决。
- iframe
- 代理
- DSH
- 安全策略
- WebSocket
现象
把 DSH 多项目工作台主页直接放进 live-shell.html 左栏 iframe，三种方式全部失败：
- 直接
iframe src=http://127.0.0.1:3080/→ iframe 空白，DSH 返回 401（BrowserAuth 拦截，服务端虽未设 X-Frame-Options 但身份校验挡住未带 cookie 的跨源请求） - 走代理
http://127.0.0.1:8091/（cookie 注入已解决 401）→ 但 live-shell 用file://双击打开时，Chrome 安全策略拦截 http iframe，报 ERR_CONNECTION_REFUSED - 8091 代理只转发了 HTTP GET 主页面 → DSH 主页内 WebSocket 连接和静态资源请求失败（WebSocket 403 + 502 Bad Gateway）
根因
- DSH 主页是带认证的受保护页面，无 cookie 直接 iframe 必 401
file://origin 加载http://127.0.0.1:*iframe 被 Chrome 视为跨协议混合内容拦截，表现为连接被拒- 初版 dsh-proxy.py 仅做 HTTP 层转发，未做 WebSocket 升级（101）与静态资源/API 请求的透传
修复
- 8091 代理：dsh-proxy.py 重写为双向 TCP 转发（socket + 线程管道），首包解析 HTTP 头注入
dsh-auth-*cookie + 改写响应头；收到 101 后转纯字节双工，WebSocket 与资源请求全透传 - 8092 本地 HTTP 服务：http-server.py 托管 live-shell.html 及全站资源，live-shell 经
http://127.0.0.1:8092/live-shell.html打开，规避 file:// 跨协议拦截 - cookie 获取：DSH 每次启动打印
dsh web: http://127.0.0.1:3080/?token=xxx，浏览器访问后浏览器自动铸造dsh-auth-*cookie；把该 cookie 值喂给代理（或用户在 live-shell 左栏 URL 输入框手动填 token URL）
注意
- DSH Desktop Hub 每次启动端口漂移，cookie 名
dsh-auth-*后随机串也会变，代理失效需重新铸 cookie - 已验证死路：
file://方式不要再试（Chrome 必拦），live-shell 必须走本地 HTTP 服务 - 代理未起 / 无有效 cookie 时，live-shell 应自动降级模拟工作台（功能无损），不能白屏