navidrome/ui/src/swNavigation.js

// Lives outside sw.js so it can be unit tested: sw.js only loads inside a
// service worker, where workbox arrives via importScripts.
export const createNavigationHandler =
  (networkOnly, offlineFallback) => async (params) => {
    try {
      // Attempt a network request.
      const response = await networkOnly.handle(params)
      // A 5xx reaches us as a normal response, but carries no usable app
      return response.status >= 500 ? offlineFallback() : response
    } catch (error) {
      // If it fails, return the cached HTML.
      return offlineFallback()
    }
  }
fix(ui): stop precaching index.html so logins can't show the wrong user (#5882) * fix(ui): stop precaching index.html so logins can't show the wrong user index.html is rendered per-user by the server: it carries __APP_CONFIG__, including the auth payload (user id, name, role, Subsonic token) when authentication comes from a reverse-proxy header. Workbox precached it, and because precacheAndRoute registers its route before the NetworkOnly NavigationRoute, every navigation to /app/ was answered from Cache Storage with a frozen copy of whoever installed the service worker. With ExtAuth, signing out and back in as a different user therefore kept showing the previous user, along with their Subsonic token. Cache Storage ignores the no-store header serve_index.go already sets, and ignores the browser's "disable cache", so only clearing site data recovered. Excluding index.html from the precache manifest lets the NetworkOnly navigation strategy do the job it was written for. Existing poisoned caches heal themselves: the entry is dropped when the new manifest activates. The same stale document caused the create-admin dialog to reappear (#3613), patched then by calling removeHomeCache() after login. That helper only ran on password login and token refresh, so it never covered the ExtAuth path, and a refetch re-poisoned the cache anyway. Fixing the cause makes it dead code, so it is removed. Also serve the offline page on 5xx: it arrives as a normal response, so the existing catch never saw it, and without a precached shell a restarting server would surface a raw gateway error. The offline copy is reworded to fit both causes. * test(ui): cover the service worker navigation fallback rules The handler lived inside sw.js, which only loads in a service worker where workbox arrives via importScripts, so none of it was reachable from vitest. Moving the decision into its own module pins the rules that matter: a 5xx falls back to the offline page like a thrown network error does, while 4xx and 304 still pass through to the app. 2026-08-02 19:46:05 -04:00			`// Lives outside sw.js so it can be unit tested: sw.js only loads inside a`
			`// service worker, where workbox arrives via importScripts.`
			`export const createNavigationHandler =`
			`(networkOnly, offlineFallback) => async (params) => {`
			`try {`
			`// Attempt a network request.`
			`const response = await networkOnly.handle(params)`
			`// A 5xx reaches us as a normal response, but carries no usable app`
			`return response.status >= 500 ? offlineFallback() : response`
			`} catch (error) {`
			`// If it fails, return the cached HTML.`
			`return offlineFallback()`
			`}`
			`}`