Service worker requests are causing a user to be perpetually 'active'

Bug
1

Whenever a client requests something from the server on Discourse, it bumps the ‘last active’ time for the user. This is used for various things, including deciding whether to email a user or not. I also use it in my whos-online plugin. Logic in discourse’s AJAX requests means that background tabs do not bump this ‘last-active’ time.

On my forum we’ve seen a few instances of users ending up perpetually online, which is annoying for the whos-online display, but also means that the user won’t receive any emails.

In all cases, checking the NGINX logs reveals that the user’s browser is making repeated (every 1-2mins) requests for /service-worker.js. The user agent string in all cases suggests this repeated request issue is limited to Firefox 56.

Does anyone have any ideas on what can be done to stop these repeated requests happening?

Should Discourse really bump the last active time whenever the service worker is requested?

6 Likes
2

We should definitely add a bypass there, but it is very concerning that this is flood requested as well, especially since it has proper cache headers

5 Likes
3

This is specific to Firefox as well?

4

If you can repro on firefox we should report this to mozilla.

Testing service workers on local is super annoying cause of the HTTPS req, but what I would recommend doing is adding some puts to #should_update_last_seen?

A simple workaround is to check for the requested content type there and only update last seen for html/js. Other possible workaround is to bypass all the filters that look at current_user for this, or even ship it via a middleware.

Overall @codinghorror this just makes me even more annoyed at service workers, it feels like an experimental feature on too many browsers at the moment.

On some sites we host I can see the service worker requested over 100 times an hour.

Example user agents where the service worker was requested more than 10 times in the last few hours.

Firefox/56.0.3 Waterfox/56.0.3

Mozilla/5.0 (iPhone; CPU OS 9_3_2 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13F69 Safari/601.1 (which is super odd) 

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

So yeah, this is all over the shop.

7 Likes
6

I think @tgxworld added caching here to make it a non issue. Right?

1 Like
7

@featheredtoast @tgxworld @david I am pretty confident this is now resolved due to a series of internal changes.

I am closing this, but be sure to flag it to be re-opened if you think it is an issue.

5 Likes