Browser issue service_worker.js HTTP auth issue

Joe Link

Well-known member
Affected version
2.2.1
Bear with me, I'm not entirely sure what I'm talking about :)

Our dev site is password protected per the XF terms. In Chrome and Edge, it looks like XF is caching the service_worker.js, preventing the display of the authentication prompt. Not a huge issue on our dev site as I know how to clear it, but I know some XF users run their entire sites behind HTTP auth.

If I open DevTools > Application, unregister service_worker.js, then refresh the prompt is shown as intended. I did some searching on Google and it looks like this is a known issue, which may be resolved by implementing something like this.
 
We did actually make a change for this in 2.2.1. Is it possible you were still using the 2.2.0 version? (The service worker won't be updated instantly when you update XF.)
 
Thanks for the quick response, Mike :)

I am on 2.2.1, have have been since the day it was released.

1604853554940.webp

To be positive, I just re-downloaded the 2.2.1 package and diffchecked the file with the one on our server, it's identical. I've cleared all site data in the browser multiple times in the past couple weeks, so I don't think it's using the old version.

Not sure if this is helpful, but when I look at the loaded service_worker.js in DevTools, this is what it looks like.

Code:
"use strict";

self.addEventListener('push', function(event)
{
    if (!(self.Notification && self.Notification.permission === 'granted'))
    {
        return;
    }

    try
    {
        var data = event.data.json();
    }
    catch (e)
    {
        console.warn('Received push notification but payload not in the expected format.', e);
        console.warn('Received data:', event.data.text());
        return;
    }

    if (!data || !data.title || !data.body)
    {
        console.warn('Received push notification but no payload data or required fields missing.', data);
        return;
    }

    data.last_count = 0;

    var options = {
        body: data.body,
        dir: data.dir || 'ltr',
        data: data
    };
    if (data.badge)
    {
        options.badge = data.badge;
    }
    if (data.icon)
    {
        options.icon = data.icon;
    }

    var notificationPromise;

    if (data.tag && data.tag_phrase)
    {
        options.tag = data.tag;
        options.renotify = true;

        notificationPromise = self.registration.getNotifications({ tag: data.tag })
            .then(function(notifications)
            {
                var lastKey = (notifications.length - 1),
                    notification = notifications[lastKey],
                    count = 0;

                if (notification)
                {
                    count = parseInt(notification.data.last_count, 10) + 1;
                    options.data.last_count = count;

                    options.body = options.body +  ' ' + data.tag_phrase.replace('{count}', count.toString());
                }

                return self.registration.showNotification(data.title, options);
            });
    }
    else
    {
        notificationPromise = self.registration.showNotification(data.title, options);
    }

    event.waitUntil(notificationPromise);
});

self.addEventListener('notificationclick', function(event)
{
    var notification = event.notification;
    
    notification.close();

    if (notification.data.url)
    {
        event.waitUntil(clients.openWindow(notification.data.url));
    }
});
 
My dev is currently on 2.2.1 and I have had this issue ever since 2.2 beta 1. Using incognito mode in Chrome (or comparable in other browsers) gets around it so I have kind of stopped worrying about it but I have posted about it a couple times.
 
Our workaround was for a couple specific locations. like the admin control panel. So it won't apply to a case where the entire directory is protected.

Unfortunately, this issue is essentially a browser bug. There is an open Chrome report about this (as they did make changes that were supposed to resolve it):


The frustrating part is that, as far as I can tell, it's not possible to easily workaround it without entirely disabling part of the functionality that is expected of a PWA (some basic offline handling).

If you're affected by this issue, it is possible to edit service_worker.js and to entirely disable the fetch functionality by adding the code in red:

Rich (BB code):
self.addEventListener('fetch', function(event)
{
return;

Note that a hard refresh will generally resolve the issue as well (since that request will display the auth popup and subsequent requests will simply include the authentication data automatically).

I'm going to leave this open for now as there is one thing I'd like to investigate, but I think it's likely that this will have to be deferred to the browsers to resolve (or a manual workaround in specific cases).
 
THanks, @Mike. Knowing it's a Chromium issue helps. Explains why I get it in both Edge and Chrome (I don't really use any other browsers at this point).
 
Still no fix or non-restricting work around for this?
It's very annoying having to use Incognito mode to access your dev/test site, especially when you cannot test push notifications.
 
Still no fix or non-restricting work around for this?
It's very annoying having to use Incognito mode to access your dev/test site, especially when you cannot test push notifications.
The latest comment on the Chromium thread Mike posted was Dec. 22 so it doesn't look like it. And Chrome 88 has come out since then and it is still doing it, for me at least.
 
Worth noting that there have been some commits related to this in Chrome that, on the face of it, should resolve the issue, though I don't know what version they might land in off hand.

The small code modification I mentioned above would resolve the issue (as I don't really see any other way that we can workaround this for now) and wouldn't cause any issues with notifications (it would, at some point in the future, disable the PWA, though the fix would hopefully land before that anyway).
 
Finally went away this week but I can't say for sure what fixed it, probably a Chromium update. I have not been in my dev for a while and noticed it was fixed when I went in to do a test run of 2.2.5. During that time, I've switched from Chrome to Edge (to be consistent between home and work) and both browsers have had multiple updates.
 
Top Bottom