多用户模式的安全配置要点

当“阅读”这类工具从个人书斋走向团队共享，多用户模式便不再是可选项，而成了必须认真对待的安全工程。很多管理员在开启这个功能时，可能仅仅是为了方便同事或家人共用资源，却没意识到，一个未经加固的多用户环境，就像把自家书房钥匙挂在门外——便捷有了，风险也敞开了。配置要点绝非只是勾选一个开关那么简单。

身份认证：第一道也是最重要的防线

启用reader.app.secure=true只是开始。一个常见的误区是使用弱密码或默认密码。系统虽允许设置最小密码长度（如minUserPasswordLength: 8），但这只是底线。最佳实践是结合注册邀请码（inviteCode）使用。邀请码机制能将用户群体控制在可信范围内，从源头上杜绝匿名注册带来的不可控风险。想想看，开放注册意味着互联网上任何嗅探到服务地址的人都能成为你的“用户”，这显然不是私有化部署的初衷。

权限隔离：不是所有用户都需要所有功能

多用户安全的核心是“最小权限原则”。配置文件中的一系列defaultUserEnable*选项正是为此而生。例如，defaultUserEnableBookSource: false意味着新用户只能使用预设书源，无法新增或修改。这有效防止了恶意书源注入——一条精心构造的恶意书源可能成为攻击者窃取其他用户书架数据甚至执行远程代码的后门。对于本地书仓（localStore）和WebDAV同步功能，也应遵循同样逻辑，只对确需使用的用户开放。

用户数据目录的物理隔离是另一个关键。当secure为true时，每个用户的数据（书架、书源、缓存）都严格存放在storage/data/用户名下，用户之间无法通过常规操作访问彼此文件。这种沙箱化的设计，比单纯依赖软件逻辑隔离更为可靠。

管理密码与运维安全

secureKey（管理密码）是一个容易被忽视但权限极高的凭证。它用于前端管理用户空间。这个密码必须与普通用户密码不同，且强度更高，并严格限制知晓范围。理想情况下，它应该定期更换，特别是在有管理员变动时。

运维层面的配置同样关乎安全。自动清理不活跃用户（autoClearInactiveUser）是个好习惯。设为30，意味着超过一个月未登录的账户将被自动清除，这能减少“僵尸账户”被利用的风险。设定合理的userLimit（用户上限）和defaultUserBookLimit（用户默认书籍上限），不仅能控制资源消耗，也是一种安全配额，防止单个用户滥用资源影响服务稳定性。

网络与数据层面的加固

服务暴露在网络上，配置要点就必须延伸到网络层。如果服务需要从公网访问，绝不应直接暴露8080端口。通过Nginx等反向代理配置HTTPS是基本操作，它能加密传输数据，防止嗅探。在反向代理配置中，严格限制client_max_body_size，可以一定程度上抵御通过上传超大文件发起的拒绝服务攻击。

数据安全包含存储和传输。对于WebDAV同步，确保使用HTTPS地址（https://...）。虽然应用内缓存（cacheChapterContent）能提升阅读体验，但在高敏感场景下，权衡后关闭它或许更安全，因为缓存内容可能以未加密形式存储在磁盘上。定期查看logs目录下的日志，尤其是当debugLog临时开启进行问题排查后，应及时关闭，避免日志泄露敏感操作信息。

说到底，多用户模式的安全配置是一个动态平衡的过程，在便利与风险之间不断寻找那个属于你自己场景的“甜蜜点”。它没有一劳永逸的方案，只有持续的关注和适配。