在容器里跑阅读服务,最怕的不是功能实现,而是安全漏洞和用户管理的盲点。把服务器想象成一扇只能让持钥匙的人进出的门,只有锁好门把手、检查每把钥匙,才能避免陌生人随意闯入。
阅读系统自带 reader.app.secure 参数,一旦设为 true,登录鉴权、用户配额、密码强度等全部生效。配合 reader.app.inviteCode 与 reader.app.secureKey,既能限制注册渠道,又能在管理后台防止随意篡改。
docker run -d
--name reader
-e READER_APP_SECURE=true
-e READER_APP_SECUREKEY=SuperSecret123
-e READER_APP_INVITECODE=Read2024
-v $(pwd)/storage:/storage
-p 8080:8080
hectorqin/reader
USER 1000),降低系统级别的权限提升风险。proxy_set_header X-Forwarded-Proto https 确保后端识别安全协议。reader.app.userLimit=15,并开启 autoClearInactiveUser 自动清理长期未登录的账号。minUserPasswordLength,并强制使用大小写+数字组合。如果已经在外网暴露,记得在 Nginx 配置里加入 client_max_body_size 20m 防止恶意大文件上传,同时开启 gzip 减轻流量压力。
很多人把环境变量写进 docker-compose.yml 时忘记使用大写下划线,导致配置未生效;还有人把 secure 设成字符串 "true" 而非布尔,结果登录绕过。遇到权限异常时,先检查容器日志 docker logs -f reader,再对照 application.properties 的实际值。
参与讨论
感觉还行,但secureKey设成固定值有点危险吧
前几天刚搞完这个,确实折腾了好久
非root用户运行这点很重要,之前就被提权搞过一次
client_max_body_size 20m 是不是太小了?传个大点的PDF直接炸了
hhh 每次写docker-compose都忘了转大写下划线,然后懵逼半天
要是用户量突然爆了,userLimit卡死没法注册咋办?
这个配置在M1上能跑吗?
自动清理不活跃账号这功能真香,省心
有人试过用ldap对接多用户吗?想搞公司内网用
密码策略能不能自定义正则啊,现在这个组合还是不够安全
666 更新这么快,等你出个完整部署教程!