为什么升级到 v11 后所有 Dozzle 用户都会被登出一次【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle把 Dozzle 升级到 v11 之后所有已登录的用户都会被登出一次。这不是配置丢了也不是users.yml被改动而是 v11 改变了会话令牌的签名方式签名密钥从由users.yml推导换成了随机生成并持久化到数据目录的session_secret文件。这篇文章说明这次变更的原因、升级前后要检查什么以及如何确认升级只造成一次登出而不是每次重启都掉会话。v11 改了什么会话令牌换了一把签名密钥Whats New in v11 的 Upgrading 一节给出了两个事实会话令牌现在用一个随机 secret 签名这个 secret 被持久化到数据目录中的session_secret文件里与users.yml并列存放。旧的密钥是从users.yml推导出来的。这个做法在每个用户都有 bcrypt 密码哈希时还算够用但 v11 同时带来了 GitHub 和 OIDC 登录属于simpleproviderusers.yml仍然是允许登录的名单。一个账号可以完全通过 OAuth 证明身份、不携带任何密码哈希此时旧密钥的熵就不够用了was not enough entropy once an account can be proven by OAuth and carry no password hash at all。把这两个事实连起来登出的原因就清楚了升级前签发的那些令牌是用旧密钥签名的升级到 v11 后 Dozzle 只认session_secret里的新密钥旧令牌全部验证失败于是每个已登录的浏览器都会回到登录页。这是一次性影响。用户重新登录后会话由持久化的新密钥签名users.yml本身在升级中不会被修改用户、角色和 filter 都原样保留。升级前确认 /data 可写新密钥的落盘位置是容器内的/data升级后的结果到底是登出一次还是每次重启都掉会话取决于这个目录是否可写。文档的标准部署形态是把宿主机目录挂载到/dataSimple Authentication 中的示例services: dozzle: image: amir20/dozzle:latest volumes: - /var/run/docker.sock:/var/run/docker.sock - /path/to/dozzle/data:/data ports: - 8080:8080 environment: DOZZLE_AUTH_PROVIDER: simple其中/path/to/dozzle/data是文档中表示宿主机数据目录的占位写法替换成你实际的挂载路径。需要确认的是这个宿主机目录对容器是可写的。如果你之前为了安全把users.yml以只读方式挂载、或者整个数据卷是只读的升级后新的session_secret就写不进去。执行升级与预期现象把镜像更新到 v11 并重启容器。升级后立刻会出现的现象所有已登录的浏览器回到登录页每个用户需要重新登录一次重新登录走原有途径密码登录或者 v11 新增的 GitHub / OIDC 登录配置方式见 Sign in with GitHub OIDC数据目录里的users.yml内容不变。升级后验证做两项检查确认会话机制处于文档预期的持久化状态session_secret文件已生成。在映射到/data的宿主机目录里session_secret应该出现在users.yml旁边。以文档示例的挂载路径为例替换为你的实际宿主机路径ls /path/to/dozzle/data列出的内容里应同时包含users.yml和session_secret。如果只有users.yml说明密钥没有落盘进入下一条。启动日志里没有密钥无法持久化的警告。文档明确说明如果/data不可写Dozzle 仍然会启动改用只存在于内存中的密钥并给出警告而这意味着每次重启都会丢失全部会话。看到这个警告时升级的代价就从一次登出变成了每次重启后全员重新登录需要修复数据目录的写入权限再重启而不是带着警告继续使用。两项都满足时本次升级的影响就收敛为那一次性的登出重新登录的会话由持久化密钥签名后续重启不会再清掉会话。限制与边界数据目录只读是一个被文档承认的真实部署形态例如把users.yml只读挂载进来Dozzle 不会因此拒绝启动代价是会话无法跨重启存活文档给出的出路就是让/data可写。如果你的部署使用 forward proxy 或独立的 OIDC provider身份在 Dozzle 之外重新登录的入口是代理或身份提供方但升级后全员登出一次的现象同样适用见 Authentication 总览。v11 的其余变化新界面、日志格式识别、alerts 持久化等与登出无关见 Whats New in v11如需了解签名密钥的生成与回退细节实现位于 internal/auth/secret.go。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
为什么升级到 v11 后所有 Dozzle 用户都会被登出一次？
为什么升级到 v11 后所有 Dozzle 用户都会被登出一次【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle把 Dozzle 升级到 v11 之后所有已登录的用户都会被登出一次。这不是配置丢了也不是users.yml被改动而是 v11 改变了会话令牌的签名方式签名密钥从由users.yml推导换成了随机生成并持久化到数据目录的session_secret文件。这篇文章说明这次变更的原因、升级前后要检查什么以及如何确认升级只造成一次登出而不是每次重启都掉会话。v11 改了什么会话令牌换了一把签名密钥Whats New in v11 的 Upgrading 一节给出了两个事实会话令牌现在用一个随机 secret 签名这个 secret 被持久化到数据目录中的session_secret文件里与users.yml并列存放。旧的密钥是从users.yml推导出来的。这个做法在每个用户都有 bcrypt 密码哈希时还算够用但 v11 同时带来了 GitHub 和 OIDC 登录属于simpleproviderusers.yml仍然是允许登录的名单。一个账号可以完全通过 OAuth 证明身份、不携带任何密码哈希此时旧密钥的熵就不够用了was not enough entropy once an account can be proven by OAuth and carry no password hash at all。把这两个事实连起来登出的原因就清楚了升级前签发的那些令牌是用旧密钥签名的升级到 v11 后 Dozzle 只认session_secret里的新密钥旧令牌全部验证失败于是每个已登录的浏览器都会回到登录页。这是一次性影响。用户重新登录后会话由持久化的新密钥签名users.yml本身在升级中不会被修改用户、角色和 filter 都原样保留。升级前确认 /data 可写新密钥的落盘位置是容器内的/data升级后的结果到底是登出一次还是每次重启都掉会话取决于这个目录是否可写。文档的标准部署形态是把宿主机目录挂载到/dataSimple Authentication 中的示例services: dozzle: image: amir20/dozzle:latest volumes: - /var/run/docker.sock:/var/run/docker.sock - /path/to/dozzle/data:/data ports: - 8080:8080 environment: DOZZLE_AUTH_PROVIDER: simple其中/path/to/dozzle/data是文档中表示宿主机数据目录的占位写法替换成你实际的挂载路径。需要确认的是这个宿主机目录对容器是可写的。如果你之前为了安全把users.yml以只读方式挂载、或者整个数据卷是只读的升级后新的session_secret就写不进去。执行升级与预期现象把镜像更新到 v11 并重启容器。升级后立刻会出现的现象所有已登录的浏览器回到登录页每个用户需要重新登录一次重新登录走原有途径密码登录或者 v11 新增的 GitHub / OIDC 登录配置方式见 Sign in with GitHub OIDC数据目录里的users.yml内容不变。升级后验证做两项检查确认会话机制处于文档预期的持久化状态session_secret文件已生成。在映射到/data的宿主机目录里session_secret应该出现在users.yml旁边。以文档示例的挂载路径为例替换为你的实际宿主机路径ls /path/to/dozzle/data列出的内容里应同时包含users.yml和session_secret。如果只有users.yml说明密钥没有落盘进入下一条。启动日志里没有密钥无法持久化的警告。文档明确说明如果/data不可写Dozzle 仍然会启动改用只存在于内存中的密钥并给出警告而这意味着每次重启都会丢失全部会话。看到这个警告时升级的代价就从一次登出变成了每次重启后全员重新登录需要修复数据目录的写入权限再重启而不是带着警告继续使用。两项都满足时本次升级的影响就收敛为那一次性的登出重新登录的会话由持久化密钥签名后续重启不会再清掉会话。限制与边界数据目录只读是一个被文档承认的真实部署形态例如把users.yml只读挂载进来Dozzle 不会因此拒绝启动代价是会话无法跨重启存活文档给出的出路就是让/data可写。如果你的部署使用 forward proxy 或独立的 OIDC provider身份在 Dozzle 之外重新登录的入口是代理或身份提供方但升级后全员登出一次的现象同样适用见 Authentication 总览。v11 的其余变化新界面、日志格式识别、alerts 持久化等与登出无关见 Whats New in v11如需了解签名密钥的生成与回退细节实现位于 internal/auth/secret.go。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考