This is stopping a customer (https://app-eu1.hubspot.com/contacts/26586079/record/0-2/10868925937) from using one of our Blueprints. They were planning to roll this out to their UK factory on Monday. It would be very good for their confidence in FF if we can maintain that timeline.

Just to make sure this has been seen @knolleary @joepavitt

Investigating now

So, we know the cause - it's due to the way that Safari caches the auth session.

The session token expires (either due to timeout, or due to an underlying instance restart). When a user then navigates to the page, Safari goes to get /dashboard/manifest.webmanifest as part of our PWA, but due to an issue with Safari and the allow access origin: *, the CORS check fails, which prevents Dashboard from getting any new content or session variables.

More details here: https://medium.com/prodigy-engineering/is-safari-getting-stricter-with-cors-8767c809c726#:~:text=If%20you%20have%20an%20issue,control%2Dallow%2Dorigin%20domains

I have installed MS Edge on MacOS and can reproduce the error (as the customer has reported this on Edge rather than safari).

To reproduce, given a NR instance serving dashboard with FF Auth enabled, start with a clean browser session having cleared the cache/cookies for the NR instance.

1. Login to FF App
2. Open the Dashboard in Edge/Safari - dashboard should load okay
3. Restart Node-RED - this flushes its cache of active login sessions for dashboard
4. Reload the dashboard page - see the error in edge/safari. No error in chrome/firefox

I have found a difference in behaviour between edge and safari that I cannot currently explain:

1. In edge, the error is hit when loading /dashboard/support-request. If you change the url to /dashboard/, it loads without error.
2. In safari, the error is hit even if the url is changed

The root issue here is the PWA handling.

The first time a user accesses the page (with nothing cached), index.html is loaded - but the request triggers the FFAuth Oauth flow and is redirected to FF to login. All works well.

Some time later (for example, after the NR instance is restarted as auth sessions are not persistent in the runtime), the user reloads the dashboard. index.html is cached and the service worker runs some fetches to validate its cache.

• index.html loads from cache - not auth challenge is made
• the service worker fetches fail authentication and get redirected - but they are background fetches, not interactive sessions. The fetches fail and errors are logged. However, we don't detect the auth failures, so can't take any action to resolve and the dashboard presents the error shown above.

In digging through the pwa stack, I found some references on handling fetch errors during the service worker cache validation stage, but I couldn't see how to relate them to the apis provided by vite-plugin-pwa. I raised vite-pwa/vite-plugin-pwa#819 to get input - but that has not had any replies other than a me-too comment from someone hitting the same type of thing.

I see two possible courses of action:

1. As I write this, I realise something I didn't dig into is what path leads to the specific error page shown above - whether there is some logic to be added there that can force a reload of index.html
2. Alternatively, add an option to disable all of the PWA capabilities as they are not fully compatible with FF Auth.