Hard Refresh (Ctrl+F5) Required After Session Expiry with Authenticated Reverse Proxy

[JasperE84]

What happened?

When using an authenticating reverse proxy (e.g., Entra App Proxy, Cloudflare Access), reverse proxy session recovery has regressed. When the proxy's session expires, API calls from the LibreChat client fail with CORS errors, as the proxy attempts to redirect the XHR requests to the login page.

(Although this may not be an official feature, it was in a usable state for the last year)

The Problem
When the reverse proxy's session token expires, API calls from the LibreChat frontend fail. The proxy intercepts the API request and tries to redirect it to our identity provider, causing a CORS error and an "Internal Server Error" dialog in the UI. (Such redirects are only accepted in the browser for full page redirects, not for API XMLHttpRequests)

The Change:

• Before: A standard refresh (F5), or navigating to https://librechat.mydomain.com/ was sufficient to trigger a full-page redirection, triggering re-authentication with the proxy. Resulting in a working state for the LibreChat app.
• After recent update: A standard refresh no longer works. Only a hard refresh (Ctrl+F5) successfully bypasses the browser cache and triggers re-authentication.

Impact: Users are stuck with an "Internal Server Error" dialog and cannot easily recover. Might the cause be a change in caching headers for index.html or the main app bundle? Re-instating a no-cache policy for the main entry point or adding a link/button in the error message triggering a full page reload might solve this issue.

Version Information

Version: ghcr.io/danny-avila/librechat-dev:0103b4b08a6ee1339569d7d4af16beaaac0228ed

Steps to Reproduce

1. Install from docker
2. Configure reverse proxy with its own session auth
3. Wait for or trigger reverse proxy session expiration (with conditional access several events can trigger this, risky logins, ip changes, etc.)
4. Navigate to librechat url

What browsers are you seeing the problem on?

Chrome, Microsoft Edge

Relevant log output

No errors in backend logs as the HTTP requests do not reach the backend.

Screenshots

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

After recent update: A standard refresh no longer works. Only a hard refresh (Ctrl+F5) successfully bypasses the browser cache and triggers re-authentication.

Certainly not the case here

You can set what these fields are via environment variables, were you utilizing these environment variables?

LibreChat/api/server/index.js

Lines 123 to 135 in 0103b4b

	app.use((req, res) => {
	res.set({
	'Cache-Control': process.env.INDEX_CACHE_CONTROL || 'no-cache, no-store, must-revalidate',
	Pragma: process.env.INDEX_PRAGMA || 'no-cache',
	Expires: process.env.INDEX_EXPIRES || '0',
	});
	const lang = req.cookies.lang || req.headers['accept-language']?.split(',')[0] || 'en-US';
	const saneLang = lang.replace(/"/g, '"');
	const updatedIndexHtml = indexHTML.replace(/lang="en-US"/g, `lang="${saneLang}"`);
	res.type('html');
	res.send(updatedIndexHtml);
	});

It looks like they changed from what they were before and forgot to be updated in the docs (will do that asap):
https://www.librechat.ai/docs/configuration/dotenv#index-html-cache-control

possibly related: https://www.librechat.ai/docs/configuration/dotenv#static-file-handling

Other than pointing to you to these configurations, I'm not sure how to help you troubleshoot further, let me know if that resolves the issue for you.

[JasperE84]

Ok first off I want to say I think it's really great you provide feedback to my edge case here!

Those code lines in index.js and their settings seem to be last modified 8months ago. I update my LibreChat instance a lot more frequent than that :).

Now running container librechat v0.7.8 from the non-dev container and its working as it should again.

By changing back and forth between the librechat:latest and librechat-dev:latest containers I noticed the following difference:

• In non-dev latest container, the request for the page reload on F5 is fulfilled by a network transfer.
  • The reverse proxy thus can intercept this, and redirect the browser window to the auth page of my identity provider, before redirecting it back to LibreChat.
• In the latest librechat-dev build on a normal refresh (F5), the browser page is however fulfilled by the service worker
  • Without fetching from network, so not triggering the re-auth on my reverse proxy IdP.

Note the most-right column in the screenshot in the background here on a normal refresh (or just typing out my librechat url in the URL bar):

That should load from network in my case to fix the issue.

Could maybe this commit introduce this 'new' behaviour regarding caching of the main page?
f556aae

If I'm on the wrong track here please bear with me. I'm just now learning about the different caching mechanisms at play and what a service worker is.

[danny-avila]

Could maybe this commit introduce this 'new' behaviour regarding caching of the main page?

Not sure, the change explicitly sets no-cache on the index.html and service worker files. You would have to test before/after that specific change to be sure.

Take a look at the main change from that commit/PR here:
https://github.com/danny-avila/LibreChat/blob/main/api/server/utils/staticCache.js

PR changes:
https://github.com/danny-avila/LibreChat/pull/7605/files

In any case, I'm not sure what would fix the issue for you, so it's hard for me to address.

[JasperE84]

I think I've found the culprit, this fixed it for me:

$ git diff -r HEAD
diff --git a/client/vite.config.ts b/client/vite.config.ts
index 98451b6c..52e3f52c 100644
--- a/client/vite.config.ts
+++ b/client/vite.config.ts
@@ -46,7 +46,7 @@ export default defineConfig(({ command }) => ({
           'assets/maskable-icon.png',
           'manifest.webmanifest',
         ],
-        globIgnores: ['images/**/*', '**/*.map'],
+        globIgnores: ['images/**/*', '**/*.map', 'index.html'],
         maximumFileSizeToCacheInBytes: 4 * 1024 * 1024,
         navigateFallbackDenylist: [/^\/oauth/, /^\/api/],
       },

In my search for this one, Roo code on Anthropic LLM, suggested an alternative fix: to make the service worker respect the cache headers. I thought that was worth mentioning here.

The service worker is caching index.html because:

• Workbox globPatterns includes HTML files: Line 42 in vite.config.ts has '**/*.{js,css,html}' which means ALL HTML files (including index.html) are being precached by the service worker.
• Service worker cache takes precedence: Even though the server sets no-store, no-cache, must-revalidate headers for index.html in staticCache.js, the service worker intercepts requests and serves from its cache first.
• No runtime caching strategy: The current configuration doesn't specify how to handle navigation requests (like the main page) at runtime.

Suggested approach for runtime caching strategy (didn't test): 

workbox: {
  // ... existing config
  runtimeCaching: [
    {
      urlPattern: ({ request }) => request.mode === 'navigate',
      handler: 'NetworkFirst',
      options: {
        cacheName: 'pages',
        networkTimeoutSeconds: 3,
        cacheKeyWillBeUsed: async ({ request }) => {
          // Don't cache if no-store header is present
          const response = await fetch(request.clone());
          const cacheControl = response.headers.get('cache-control');
          if (cacheControl && cacheControl.includes('no-store')) {
            return null; // Don't cache
          }
          return request.url;
        }
      }
    }
  ]
}

[danny-avila]

I see, thank you for looking into this.

Workbox globPatterns includes HTML files: Line 42 in vite.config.ts has '**/*.{js,css,html}

I think it would be safe enough to adjust the pattern expression to exclude index.html.

The runtime caching strategy is interesting but it looks like cacheKeyWillBeUsed is a not a valid options field.

[JasperE84]

Yeah the exclude is probably the most simple way to fix this, and maybe exclude all or not include any patterns if caching is disabled in librechat yaml options.

I did see cachekeywillbeused mentioned in the docs, but thats probably a too complex approach, considering the above is easier to implement and should functionally have the same end result.

https://developer.chrome.com/docs/workbox/using-plugins

[danny-avila]

Made the simple change here: #7982

[JasperE84]

Made the simple change here: #7982

I do see it in the description but I think you might've missed it in de commit add. vite.config.ts is not marked as a changed file in this pr: https://github.com/danny-avila/LibreChat/pull/7982/files

Current dev branch:

LibreChat/client/vite.config.ts

Line 49 in 9708507

globIgnores: ['images/**/*', '**/*.map'],

[JasperE84]

@danny-avila, I by the way do think this is a bug. This is the behaviour I observed: Service worker cache takes precedence: Even though the server sets no-store, no-cache, must-revalidate headers for index.html in staticCache.js, the service worker running in the browser intercepts requests and serves from its cache first.

Also, disabling the cache in librechat.yaml (applied at the server via cache headers) doesnt apply if the serviceworker caches all those resources (and ignores those headers).

I dont think this behaviour is limited to my Entra reverse proxy setup. Havent tested to be sure though.