Plash应用中Basic Auth与WebSocket的认证冲突问题解析

背景概述

Plash作为一款基于WebView的桌面应用容器，在处理需要Basic Auth认证的网页时，用户反馈了一个特殊现象：即使已成功保存认证凭据，应用重启后仍会重复弹出登录对话框。经过技术排查，发现这与WebSocket连接的认证机制存在关联性。

问题本质

当网页同时存在以下两种要素时会出现该现象：

1. 主页面采用HTTP Basic Auth认证
2. 页面内建立了同源的WebSocket(wss://)连接

核心矛盾在于：WebView对WebSocket连接会独立发起认证请求，而系统凭据管理器可能无法自动传递凭据给WebSocket通道。

技术原理深度解析

1. Basic Auth的工作机制：认证信息通过Authorization头传递，浏览器会缓存并在后续请求中自动附加
2. WebSocket的特殊性：作为独立TCP连接，其握手阶段需要单独处理HTTP头
3. WebView的实现差异：相比Safari普通窗口，私有窗口和Plash这类容器对凭据传递有更严格的安全策略

解决方案

1. 架构优化方案：将WebSocket端点移出Basic Auth保护范围（需确保该端点无敏感操作）
2. 配置调整方案：在服务端设置CORS策略，明确允许凭据传递
3. 客户端方案：通过Plash的URL拦截功能，单独处理WebSocket连接的认证头

最佳实践建议

1. 现代Web应用建议采用Token-based认证替代Basic Auth
2. 必须使用Basic Auth时，建议将API端点与WS端点分不同子域
3. 对于需要严格安全的场景，应考虑使用双向TLS认证替代HTTP层认证

开发者启示

该案例典型展示了网络协议层与应用层安全的交互复杂性。在混合使用不同网络协议时，需要特别注意认证状态的同步问题。作为应用容器开发者，应当考虑增加WebSocket连接的凭据自动传递机制，或在文档中明确说明此类边界情况。