KeeWeb服务工作者缓存与HTTP基础认证冲突问题解析

背景概述

KeeWeb作为一款优秀的密码管理工具，其Web版本在自托管环境下可能会遇到服务工作者(Service Worker)缓存机制与HTTP基础认证(Basic Authentication)的兼容性问题。当两者结合使用时，会导致浏览器无法正常弹出认证对话框，进而影响应用功能。

问题现象

在特定部署场景下，用户访问受HTTP基础认证保护的KeeWeb实例时：

1. 首次加载正常显示认证对话框
2. 后续访问时由于Service Worker缓存了index.html
3. 浏览器不再发起新的认证请求
4. 所有后续API请求因缺乏认证凭据而静默失败

技术原理分析

Service Worker缓存机制

Service Worker作为现代Web应用的核心技术，通过拦截网络请求实现离线功能。它会缓存关键资源如index.html，导致后续请求直接从缓存获取，跳过了正常的HTTP请求流程。

HTTP基础认证特点

基础认证依赖HTTP头部的WWW-Authenticate响应头触发浏览器认证对话框。当资源从Service Worker缓存获取时，浏览器不会收到这个头部，因此不会提示用户输入凭据。

WebDAV集成影响

在所述案例中，WebDAV存储后端也需要通过相同的认证域访问，这使得整个认证流程更加复杂。所有未经认证的请求都会静默失败，而用户只能看到加载失败界面。

解决方案实践

方案一：禁用Service Worker

1. 替换service-worker.js为空文件
2. 优点：简单直接，完全避免缓存问题
3. 缺点：失去离线功能优势

方案二：Nginx配置优化

location / {
    add_header Cache-Control "no-store, no-cache";
    expires off;
    etag off;
}

通过强制禁用缓存确保每次请求都经过服务器验证。

方案三：条件式Service Worker注册

在index.html中添加逻辑判断：

if(!window.location.href.includes('auth-required')) {
    navigator.serviceWorker.register('/service-worker.js');
}

最佳实践建议

1. 对于安全敏感的应用，建议采用方案一彻底禁用Service Worker
2. 如需保留Service Worker功能，应考虑改用基于Cookie或Token的认证方式
3. 在Nginx配置中确保对API路径禁用缓存
4. 考虑将应用前端和API部署在不同子域，分别处理认证

安全注意事项

1. 禁用缓存可能影响性能但提升安全性
2. 基础认证应始终配合HTTPS使用
3. 定期轮换认证凭据
4. 考虑实现会话超时机制

通过以上分析和解决方案，管理员可以根据实际安全需求和功能要求，选择最适合自己KeeWeb实例的配置方式。