Why Are Session Cookies Lost in Firefox for a Rails/Devise App on Production?

Below is one likely explanation tied to how Firefox’s service worker implementation interacts with sessions and cookies.

What’s Likely Happening

Even though your service worker is currently a minimal stub, it still intercepts all fetch requests by design. In Firefox (in a non-private window), this interception may cause requests to bypass the regular cookie-handling flow. In your case, after account creation the Rails (and Devise) sign-in resets the session, which requires the client to receive a new cookie. A misbehaving or unconfigured service worker can interfere with that setup by:

• Returning a cached or previously intercepted response that lacks the updated session cookie headers.
• Handling the fetch request in a way that prevents Firefox from sending or receiving the proper cookies.

In contrast, Chrome (or Firefox in a Private Window) doesn’t exhibit the same behavior—possibly due to differences in caching strategies or how service workers are managed in those environments.

How to Investigate Further

1. Disable the Service Worker: As you discovered, unregistering the service worker stops the issue. This confirms that the fetch interception by the service worker is interfering with the session cookie delivery.

2. Examine the Fetch Handling: Even if you’re not doing any custom behavior in the fetch event, by simply listening to fetch events you might be overriding the browser’s default behavior. Ensure that your event listener doesn’t inadvertently call event.respondWith() with a response that misses updated cookies.

3. Review Caching Policies: If your service worker ever adds caching behavior for responses that include session cookies, ensure that you’re not caching authenticated responses or missing proper client validation.

Possible Fixes

• Skip Intercepting Auth Requests: You can add logic in your service worker’s fetch event to bypass interception on routes related to sign-in and session management. For example:

  JAVASCRIPTCopied
  self.addEventListener('fetch', event => {
    // Bypass the service worker for auth-related requests.
    if (event.request.url.includes('/users/sign_in') ||
        event.request.url.includes('/users/sign_up')) {
      return;
    }
    // Normal fetch handling.
    event.respondWith(fetch(event.request));
  });

• Update the Service Worker: If the service worker isn’t doing much at this point, consider unregistering it on pages where you need proper session management until you can fully test proper caching and response handling.

• Ensure Response Headers Are Forwarded: Make sure that when your service worker intercepts a response, it forwards all headers including Set-Cookie headers so that the browser updates the session cookie correctly.

Final Thoughts

This behavior highlights how even a simple service worker can affect session handling on certain browsers. The Rails security documentation stresses proper session management—including expiring sessions and transferring values when needed—but here the issue isn’t with Yii’s approach but how the browser (Firefox) deals with service workers and cookies.

Addressing this by adjusting your service worker should let you restore the expected Devise session behavior on production Firefox.