Dashy 如何配置 enableAuthProxyCompat 避免会话过期后 PWA 卡在缓存页面【免费下载链接】dashy A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!项目地址: https://gitcode.com/GitHub_Trending/da/dashy在 Dashy 前面加了一层重定向式的认证代理比如 Cloudflare Access、Authelia 这类 forward auth或 Cloudflare Tunnel / Tailscale Funnel 这类隧道并且开启了 PWA 的 service worker 之后会出现这样一个问题你的代理会话过期时service worker 缓存的应用会继续展示旧页面而不是让代理把请求重定向到登录页整个界面就卡在一块失效的缓存页面上。enableAuthProxyCompat就是 Dashy 为这个场景准备的开关配合enableServiceWorker一起开启后Dashy 会在页面加载时检测到会话过期移除 service worker 并刷新页面让代理正常完成登录重定向。什么情况下会遇到这个问题需要同时满足两个条件Dashy 部署在某个会做登录重定向的代理或隧道后面。other-auth-methods 文档中明确列出的适用范围是redirect-based proxies or tunnels例如 Cloudflare Tunnel Cloudflare Access、Tailscale Funnel、Authelia / Authentik 等 forward auth 反向代理appConfig.enableServiceWorker为true该功能默认是关闭的开启后 Dashy 才具备离线访问能力。对应的现象在 Cloudflare Tunnel 文档的故障排查章节有明确描述会话过期后Dashy 一直显示一块失效的缓存页面而不是重定向到 Cloudflare 登录页。如果你没有开启 service worker或者根本没有代理层例如走的是 Dashy 内置认证则不存在这个问题也不需要这个配置项。修改配置文件Dashy 的应用配置写在conf.yml中默认位置为仓库示例中的 user-data/conf.ymlDocker 部署时该文件以 volume 方式传入。修改可以直接编辑这个 YAML 文件也可以通过 Dashy 的 UI 编辑并保存。需要说明的是只有运行在 Docker 容器或 Node server 中的 Dashy 才支持把 UI 中的修改写回磁盘conf.yml会被更新并在同目录生成备份否则 UI 改动只保存在浏览器本地详见 configuring.md。在appConfig下加入以下两行appConfig: enableServiceWorker: true # Optional: enables the PWA and offline support enableAuthProxyCompat: true # Recover the PWA after a session expires (needs the service worker)enableServiceWorker: true是前提oidc 文档的 Using with a PWA 一节和 other-auth-methods 文档都要求两者同时开启enableAuthProxyCompat默认为false仅在enableServiceWorker: true且 Dashy 位于认证代理之后时才有意义见 configuring.md 对该字段的说明。配置保存后重新加载页面即可生效无需其他改动。这个开关实际做了什么Dashy 在加载时读取conf.yml当enableServiceWorker和enableAuthProxyCompat都为true时会先用no-store方式探测/get-user接口并手动跟踪重定向见 InitServiceWorker.js 中的recoverFromAuthProxy如果请求没有被代理重定向会话有效什么都不做继续正常的 service worker 注册流程如果检测到代理重定向会话已过期且当前页面正被 service worker 控制则注销 service worker 并执行一次页面刷新代理随后就能把用户带到登录页该刷新带有防护每个标签页只自动重载一次sessionStorage中的 guard避免在误判时反复刷新。也就是说这个开关只影响会话过期这一刻的恢复路径日常访问时的离线缓存行为保持不变网络错误/离线时探测失败会保留 service worker离线功能不受影响。结果验证文档给出的成功条件是行为层面的开启后当代理会话过期时Dashy detects the expiry on load and reloads so you can sign in againoidc 文档、Dashy will then detect the expiry on load and reload so Cloudflare can redirect you to log in againCloudflare Tunnel 文档。因此验证方法是走完一遍真实的过期流程正常登录并使用 Dashy等到代理会话到期或直接登出代理侧会话然后重新打开或刷新 Dashy 页面。预期行为是页面不再停留在失效的缓存内容上而是被重定向到代理的登录页完成再次登录修复前的现象则是卡在缓存的旧页面无法跳转。边界与替代方案该开关只在 service worker 已开启时生效两个开关缺一都不会触发恢复逻辑如果你根本不需要离线/PWA 能力直接把enableServiceWorker设为false也能消除这类缓存问题——configuring.md 同样指出 service worker 有时会缓存旧内容、需要强制刷新这是关闭它的另一个理由。两者取舍在于是否要保留离线访问该配置只解决过期后卡在缓存页这一个环节代理侧的其他问题如 Cloudflare Tunnel 下的proxyWhitelist配错导致的 401需要按 Cloudflare Tunnel 文档的故障排查章节另行处理。【免费下载链接】dashy A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!项目地址: https://gitcode.com/GitHub_Trending/da/dashy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dashy 如何配置 enableAuthProxyCompat 避免会话过期后 PWA 卡在缓存页面
Dashy 如何配置 enableAuthProxyCompat 避免会话过期后 PWA 卡在缓存页面【免费下载链接】dashy A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!项目地址: https://gitcode.com/GitHub_Trending/da/dashy在 Dashy 前面加了一层重定向式的认证代理比如 Cloudflare Access、Authelia 这类 forward auth或 Cloudflare Tunnel / Tailscale Funnel 这类隧道并且开启了 PWA 的 service worker 之后会出现这样一个问题你的代理会话过期时service worker 缓存的应用会继续展示旧页面而不是让代理把请求重定向到登录页整个界面就卡在一块失效的缓存页面上。enableAuthProxyCompat就是 Dashy 为这个场景准备的开关配合enableServiceWorker一起开启后Dashy 会在页面加载时检测到会话过期移除 service worker 并刷新页面让代理正常完成登录重定向。什么情况下会遇到这个问题需要同时满足两个条件Dashy 部署在某个会做登录重定向的代理或隧道后面。other-auth-methods 文档中明确列出的适用范围是redirect-based proxies or tunnels例如 Cloudflare Tunnel Cloudflare Access、Tailscale Funnel、Authelia / Authentik 等 forward auth 反向代理appConfig.enableServiceWorker为true该功能默认是关闭的开启后 Dashy 才具备离线访问能力。对应的现象在 Cloudflare Tunnel 文档的故障排查章节有明确描述会话过期后Dashy 一直显示一块失效的缓存页面而不是重定向到 Cloudflare 登录页。如果你没有开启 service worker或者根本没有代理层例如走的是 Dashy 内置认证则不存在这个问题也不需要这个配置项。修改配置文件Dashy 的应用配置写在conf.yml中默认位置为仓库示例中的 user-data/conf.ymlDocker 部署时该文件以 volume 方式传入。修改可以直接编辑这个 YAML 文件也可以通过 Dashy 的 UI 编辑并保存。需要说明的是只有运行在 Docker 容器或 Node server 中的 Dashy 才支持把 UI 中的修改写回磁盘conf.yml会被更新并在同目录生成备份否则 UI 改动只保存在浏览器本地详见 configuring.md。在appConfig下加入以下两行appConfig: enableServiceWorker: true # Optional: enables the PWA and offline support enableAuthProxyCompat: true # Recover the PWA after a session expires (needs the service worker)enableServiceWorker: true是前提oidc 文档的 Using with a PWA 一节和 other-auth-methods 文档都要求两者同时开启enableAuthProxyCompat默认为false仅在enableServiceWorker: true且 Dashy 位于认证代理之后时才有意义见 configuring.md 对该字段的说明。配置保存后重新加载页面即可生效无需其他改动。这个开关实际做了什么Dashy 在加载时读取conf.yml当enableServiceWorker和enableAuthProxyCompat都为true时会先用no-store方式探测/get-user接口并手动跟踪重定向见 InitServiceWorker.js 中的recoverFromAuthProxy如果请求没有被代理重定向会话有效什么都不做继续正常的 service worker 注册流程如果检测到代理重定向会话已过期且当前页面正被 service worker 控制则注销 service worker 并执行一次页面刷新代理随后就能把用户带到登录页该刷新带有防护每个标签页只自动重载一次sessionStorage中的 guard避免在误判时反复刷新。也就是说这个开关只影响会话过期这一刻的恢复路径日常访问时的离线缓存行为保持不变网络错误/离线时探测失败会保留 service worker离线功能不受影响。结果验证文档给出的成功条件是行为层面的开启后当代理会话过期时Dashy detects the expiry on load and reloads so you can sign in againoidc 文档、Dashy will then detect the expiry on load and reload so Cloudflare can redirect you to log in againCloudflare Tunnel 文档。因此验证方法是走完一遍真实的过期流程正常登录并使用 Dashy等到代理会话到期或直接登出代理侧会话然后重新打开或刷新 Dashy 页面。预期行为是页面不再停留在失效的缓存内容上而是被重定向到代理的登录页完成再次登录修复前的现象则是卡在缓存的旧页面无法跳转。边界与替代方案该开关只在 service worker 已开启时生效两个开关缺一都不会触发恢复逻辑如果你根本不需要离线/PWA 能力直接把enableServiceWorker设为false也能消除这类缓存问题——configuring.md 同样指出 service worker 有时会缓存旧内容、需要强制刷新这是关闭它的另一个理由。两者取舍在于是否要保留离线访问该配置只解决过期后卡在缓存页这一个环节代理侧的其他问题如 Cloudflare Tunnel 下的proxyWhitelist配错导致的 401需要按 Cloudflare Tunnel 文档的故障排查章节另行处理。【免费下载链接】dashy A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!项目地址: https://gitcode.com/GitHub_Trending/da/dashy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考