I'm getting logged out regularly
I've deleted all data associated with the extension, as well as the files from the server.
I reached out to Senky, the extension creator for help.
I reached out to Senky, the extension creator for help.
To the beaten, the broken, or the damned; the lost, and the wayward: wherever I may be, you will have a home.
-
spacemonaut Bauble reclaimer
- Posts: 1374
- Joined: 4 years ago
- Pronoun: she / her
- Location: Scotland
So far so good. Nice catch!Feyd_Ruin wrote: ↑2 years agoERMERGERD. Ok, so I went diving into the sessions tables and logs, and noticed something.
3drinks, you created a new session when you visited viewforum.php?f=24
18 seconds later you created a new session by visiting app.php/senky_pushnotifications_sw.js
...it's been the push notifications this whole time.
Somehow even with them being disabled, it was still hitting the offending page.
I've deleted the data completely from the server.
Lets see if it occurs now...
-
The Fluff Le fou, c'est moi
- Posts: 2398
- Joined: 4 years ago
- Pronoun: Unlisted
- Location: Gradius Home World
- Contact:
looks like it's finally solved. Not getting logged out anymore. It's been 3 days.
AnimEVO 2020 - EFZ Tournament (english commentary) // Clearing 4 domain with Qiqi
want to play a control deck in modern, but don't have Jace or snapcaster? please come visit us at the Emeria thread
-
spacemonaut Bauble reclaimer
- Posts: 1374
- Joined: 4 years ago
- Pronoun: she / her
- Location: Scotland
Same here
-
spacemonaut Bauble reclaimer
- Posts: 1374
- Joined: 4 years ago
- Pronoun: she / her
- Location: Scotland
Several days of clear skies on this front — seems safe to say you fixed it and found the right culprit
-
spacemonaut Bauble reclaimer
- Posts: 1374
- Joined: 4 years ago
- Pronoun: she / her
- Location: Scotland
@Feyd_Ruin This just happened to me again, just now (and not earlier today). Did the extension get put back?
It did not.
An occasional random logout every few weeks isn't entirely unexpected. There's probably a random custom site link that didn't have the ?sid added to it etc. now if it happens again anytime soon, we're back to looking at bugs.
An occasional random logout every few weeks isn't entirely unexpected. There's probably a random custom site link that didn't have the ?sid added to it etc. now if it happens again anytime soon, we're back to looking at bugs.
To the beaten, the broken, or the damned; the lost, and the wayward: wherever I may be, you will have a home.
-
spacemonaut Bauble reclaimer
- Posts: 1374
- Joined: 4 years ago
- Pronoun: she / her
- Location: Scotland
Gotcha. It hasn't happened again since.
-
The Fluff Le fou, c'est moi
- Posts: 2398
- Joined: 4 years ago
- Pronoun: Unlisted
- Location: Gradius Home World
- Contact:
logged out when I went to the forum today. Will report if it repeats tomorrow.
AnimEVO 2020 - EFZ Tournament (english commentary) // Clearing 4 domain with Qiqi
want to play a control deck in modern, but don't have Jace or snapcaster? please come visit us at the Emeria thread
This problem has reared its ugly head for me again today.
Browser: Firefox
Able to be replicated? Yes, it's happened twice in a row.
What's happening? Every time I navigate to the site, I have to log back in.
Browser: Firefox
Able to be replicated? Yes, it's happened twice in a row.
What's happening? Every time I navigate to the site, I have to log back in.
EDH decks and themes I'm currently playing!
Show
Hide
Tresserhorn (zombies, check out my primer!]) | Roon (blink) | Vial Smasher+Thrasios (big dudes) | Marath (tokens) | Jhoira (artifacts) | Thassa (sea monsters)
Jodah (flavor text tribal) | Slivers/Atogs/Allies/Spirits (5c tribal modular) | Xantcha (group slug) | Gitrog (non-combo)
Zur (cycling) | Yennett (spyhinx control) | Geist (1v1) | Kamahl (1v1) | Grenzo (goblins) | Bolas (discard)
Kadena (morph) | Kenrith (legendary activated abilities) | Nethroi (reanimator) | Xyris (combat tricks) | Ayula (bears)
Jodah (flavor text tribal) | Slivers/Atogs/Allies/Spirits (5c tribal modular) | Xantcha (group slug) | Gitrog (non-combo)
Zur (cycling) | Yennett (spyhinx control) | Geist (1v1) | Kamahl (1v1) | Grenzo (goblins) | Bolas (discard)
Kadena (morph) | Kenrith (legendary activated abilities) | Nethroi (reanimator) | Xyris (combat tricks) | Ayula (bears)
Hi there, Teebling here.
I'm the admin of another phpBB-based website called diablo2.io. I came across this topic whilst trying to troubleshoot my own issues with Senky's 'Push Notifications' extension, and a lot of it sounded similar to issues I've been having.
So I'm here to share my own findings which might be helpful to the admin of MTG Nexus. I can't prove for certain that there is a correlation between the broken push notifications extension and the issue where users are being randomly logged out, but I, like @Feyd_Ruin, suspect that it is the case by the looks of the sessions table. I was also getting reports of random log-outs from users, and these reports started after enabling the push notifications extension.
Either way, the push notifications ext that Senky published is broken (my users were receiving dozens of notifications for the same event), the developer is AWOL and does not respond to emails, so I too gave up on trying to fix the ext and opted to completely disable it. However, I don't think that Senky ever wrote a proper uninstall script, or considered how to let admins really, fully disable the extension, because after complete removal from server-side, requests to the push notifications script were still occurring in absurdly high numbers and clogging up the server. I was still getting tens of thousands of HTTP requests every day to the path /app.php/senky_pushnotifications_sw.js, long after removing it from the server.
Here's the steps I took to try and shut down the push notifications stuff completely. These are very standard and the admin will have 99% done all these steps already, but I am posting them here again just for clarity and consistency, and perhaps for future readers who are in the same situation:
I double-checked all my steps again, and confirmed that server-side was completely clean and nothing remained of the push notifications ext. So why was the server still getting requests to /app.php/senky_pushnotifications_sw.js? Well the _sw in that filepath indicates 'Service Worker'. It appears that the way the ext worked was to 'register' a Service Worker on the client's browser in local app storage (bit like LocalStorage). Any time the user enabled push notifications, they would get that service worker registered to their local browser storage basically. So even after completely removing the push notifications ext from server-side, the zombie service workers still existed on every client's browser that had ever used the push notifications.
So anyone who had ever used them or tried to enable them before, still had old Service Workers requesting the path /app.php/senky_pushnotifications_sw.js. In their local browser storage. THIS is what was causing the script to continue requesting that path! Those people re-visiting the site still had instructions in their browser to check that path, because the extension never 'unregistered' the service workers. You can see the service worker in Chrome Dev tools under the 'Application' or 'Storage' tab on other browsers. You'll see maybe 3-4 service workers registered there - they will point to the push notifications _sw file as mentioned.
So, how to get thousands (unknown numbers really) of site visitors to unregister/delete/remove these service workers? Obviously many have gone inactive, so you can't just give people instructions to go into the developer tools and remove the service workers themselves. Not many would attempt following your instructions, and those that would might have difficulty because it's not exactly the most user friendly thing to try and do. So that leaves one last option, which is to try and remove the old service workers programatically. That is, to force visitor's browsers to unregister the old push notification service workers automatically on page load.
To do this, I put the following at the very bottom of overall_footer.html (just before the CRON task trigger):
Remember to refresh your template cache (/cache/production/twig) from ACP or command line, so that your overall_footer.html file actually loads the new script inclusion.
It worked. Here are some screenshots from my Cloudflare analytics showing the requests to that path dropping dramatically as more and more visitors' browsers had the service worker removed:
I will keep this script in my footer for a month or so, to try and get as many of the active userbase to unregister the service workers. It may have to remain indefinitely, or at least until the next rise in traffic due to something game-related, to capture and destroy as many old SWs as possible. One nuance to this is that it won't work if the visitor has multiple tabs open, so until they visit with just one tab open on the page, it won't have an effect. After this, I plan to edit my .htaccess file to basically return a 403 permission denied error to any requests for the path /app.php/senky_pushnotifications_sw.js, so that if there are any trickles of it coming in afterwards, at least my server just gives a 403 instead of trying to look for the file and then returning a 404.
I cannot say for sure that this will fix the random user log outs, but as we both believe the two are linked, this is a good place to start - gives us the chance to at least test and see if users are still reporting the log outs in the knowledge that the effect of the old push notification SWs is decreasing day by day. Also, I think that some browsers, after 24 hours of receiving 404s, will automatically unregister the SWs, so that should future proof the solution if true.
Hope that this helps - if there's anything else you want to ask me feel free.
I'm the admin of another phpBB-based website called diablo2.io. I came across this topic whilst trying to troubleshoot my own issues with Senky's 'Push Notifications' extension, and a lot of it sounded similar to issues I've been having.
So I'm here to share my own findings which might be helpful to the admin of MTG Nexus. I can't prove for certain that there is a correlation between the broken push notifications extension and the issue where users are being randomly logged out, but I, like @Feyd_Ruin, suspect that it is the case by the looks of the sessions table. I was also getting reports of random log-outs from users, and these reports started after enabling the push notifications extension.
Either way, the push notifications ext that Senky published is broken (my users were receiving dozens of notifications for the same event), the developer is AWOL and does not respond to emails, so I too gave up on trying to fix the ext and opted to completely disable it. However, I don't think that Senky ever wrote a proper uninstall script, or considered how to let admins really, fully disable the extension, because after complete removal from server-side, requests to the push notifications script were still occurring in absurdly high numbers and clogging up the server. I was still getting tens of thousands of HTTP requests every day to the path /app.php/senky_pushnotifications_sw.js, long after removing it from the server.
Here's the steps I took to try and shut down the push notifications stuff completely. These are very standard and the admin will have 99% done all these steps already, but I am posting them here again just for clarity and consistency, and perhaps for future readers who are in the same situation:
- I disabled the ext from the Customise tab in the ACP
- I deleted the ext's data from the Customise tab in the ACP
- I cleared phpBB's cache from the ACP (or you can rm -rf /cache/production completely if shell access)
- I then completely removed the /ext/senky/pushnotifications directory using rm -rf (deleting the folder in FTP would be fine too if no shell access)
- I purged all sessions from the ACP (or you can truncate/empty - NOT drop! - the phpbb_sessions table from phpMyAdmin)
- I then cleared my browser's cache, including site data and cookies (Safari OS X, Firefox, Chrome)
- I did a find command from shell to make sure there were absolutely no files associated with senky's push extensions left anywhere on the server, to confirm that all related files had been removed. The search returned empty so I know that not a shred of the ext existed on the server now.
- I then restarted Apache/MySQL services from shell/hosting panel, just in case any rogue PHP processes were still running server-side.
- I then restarted my whole server (full power cycle), just in case there were any other related processes that would need terminating.
I double-checked all my steps again, and confirmed that server-side was completely clean and nothing remained of the push notifications ext. So why was the server still getting requests to /app.php/senky_pushnotifications_sw.js? Well the _sw in that filepath indicates 'Service Worker'. It appears that the way the ext worked was to 'register' a Service Worker on the client's browser in local app storage (bit like LocalStorage). Any time the user enabled push notifications, they would get that service worker registered to their local browser storage basically. So even after completely removing the push notifications ext from server-side, the zombie service workers still existed on every client's browser that had ever used the push notifications.
So anyone who had ever used them or tried to enable them before, still had old Service Workers requesting the path /app.php/senky_pushnotifications_sw.js. In their local browser storage. THIS is what was causing the script to continue requesting that path! Those people re-visiting the site still had instructions in their browser to check that path, because the extension never 'unregistered' the service workers. You can see the service worker in Chrome Dev tools under the 'Application' or 'Storage' tab on other browsers. You'll see maybe 3-4 service workers registered there - they will point to the push notifications _sw file as mentioned.
So, how to get thousands (unknown numbers really) of site visitors to unregister/delete/remove these service workers? Obviously many have gone inactive, so you can't just give people instructions to go into the developer tools and remove the service workers themselves. Not many would attempt following your instructions, and those that would might have difficulty because it's not exactly the most user friendly thing to try and do. So that leaves one last option, which is to try and remove the old service workers programatically. That is, to force visitor's browsers to unregister the old push notification service workers automatically on page load.
To do this, I put the following at the very bottom of overall_footer.html (just before the CRON task trigger):
<script> if(window.navigator && navigator.serviceWorker) { navigator.serviceWorker.getRegistrations() .then(function(registrations) { for(let registration of registrations) { registration.unregister(); } }); } </script>As you can see it's pretty simple ^ just a bit of javascript that tells the browser to unregister any service workers related to the site from their browser. When the user visits any page, the old service workers are unregistered/deleted forever. This means that every time one of those 'afflicted' users visits any page on the site, they will be finally released from the push notifications, and your server won't have to deal with their requests any more. Note that this will delete ALL service workers from the site, so if you are using SWs for other things, they will be deleted too (might want to double check that before you run this script in production).
Remember to refresh your template cache (/cache/production/twig) from ACP or command line, so that your overall_footer.html file actually loads the new script inclusion.
It worked. Here are some screenshots from my Cloudflare analytics showing the requests to that path dropping dramatically as more and more visitors' browsers had the service worker removed:
I will keep this script in my footer for a month or so, to try and get as many of the active userbase to unregister the service workers. It may have to remain indefinitely, or at least until the next rise in traffic due to something game-related, to capture and destroy as many old SWs as possible. One nuance to this is that it won't work if the visitor has multiple tabs open, so until they visit with just one tab open on the page, it won't have an effect. After this, I plan to edit my .htaccess file to basically return a 403 permission denied error to any requests for the path /app.php/senky_pushnotifications_sw.js, so that if there are any trickles of it coming in afterwards, at least my server just gives a 403 instead of trying to look for the file and then returning a 404.
I cannot say for sure that this will fix the random user log outs, but as we both believe the two are linked, this is a good place to start - gives us the chance to at least test and see if users are still reporting the log outs in the knowledge that the effect of the old push notification SWs is decreasing day by day. Also, I think that some browsers, after 24 hours of receiving 404s, will automatically unregister the SWs, so that should future proof the solution if true.
Hope that this helps - if there's anything else you want to ask me feel free.
Last edited by Teebling 2 years ago, edited 2 times in total.
Just for reference I did check and I had a bunch of those workers and was able to kill them.
I will definitely go with your unregistering script.
I didn't even think about zombie services on clients.
>_<
THANK YOU TEEBLING!!
I didn't even think about zombie services on clients.
>_<
THANK YOU TEEBLING!!
To the beaten, the broken, or the damned; the lost, and the wayward: wherever I may be, you will have a home.
-
3drinks Kaalia's Personal Liaison
- Posts: 4830
- Joined: 4 years ago
- Pronoun: he / him
- Location: Ruined City of Drannith, Ikoria
So what do I need to do? I've used Firefox on my laptop, Waterfox on my PC, DuckDuckGo browser on my work device, and Fennec F-Droid on my OnePlus 8.
@Feyd_Ruin if this script works globally so I need no further input, that'd be great. If I just need to log in on each browser, just lmk and I'm happy to help you purge from at least my end.
@Feyd_Ruin if this script works globally so I need no further input, that'd be great. If I just need to log in on each browser, just lmk and I'm happy to help you purge from at least my end.
Steel Sabotage'ng Orbs of Mellowness since 2011.
Modern
87guide Burn
87guide Burn
Commander
Kellan, the Fae-Blooded // Birthright Boon (local secret santa gift)
Torbran, Thane of Red Fell (Red Deck Wins)
Alesha, Who Smiles at Death (Slivers)
Kaalia HQ
Kellan, the Fae-Blooded // Birthright Boon (local secret santa gift)
Torbran, Thane of Red Fell (Red Deck Wins)
Alesha, Who Smiles at Death (Slivers)
Kaalia HQ
I'm at dayjob currently, but when I get home I'll add in the unregister script, and then whenever your browsers hit it, it should remove it.
To the beaten, the broken, or the damned; the lost, and the wayward: wherever I may be, you will have a home.
Np, let me know how you get on.
Here's last 24h since I included the SW removal script:
As you can see the number of requests has reduced substantially, but there are still small blips where requests are being made. These small blips mainly seem to come from Firefox clients, so perhaps FF caches the Service Workers for longer than Chrome or something like that. I might try and find another snippet to clear SW caches as well to counteract this. Have asked some users to test and see if the script worked for them in FF, so will report back on that.
Good luck
At some point I'm going to dig through Senky's push notification code and see if I can fix the actual issue. If I actually manage to fix it, I'll pay you back with letting you know how heh
To the beaten, the broken, or the damned; the lost, and the wayward: wherever I may be, you will have a home.
...and it's live. So hopefully any remaining bit still causing anyone an issue will be gone soon enough.
To the beaten, the broken, or the damned; the lost, and the wayward: wherever I may be, you will have a home.
-
spacemonaut Bauble reclaimer
- Posts: 1374
- Joined: 4 years ago
- Pronoun: she / her
- Location: Scotland
What browser are you using? Does this happen on other sites on that browser to which you're logged in?
That it's only happening on one device suggests it's something device-specific — either how this site is handling that browser's communications, or that browser just isn't storing the session for long.
spacemonaut wrote: ↑1 year agoWhat browser are you using? Does this happen on other sites on that browser to which you're logged in?
Its on chrome for ios, I'm not logged on any other sites on the phone but I will check out.
Does it do it while you're actively browsing, or does it seem like it just always does it at beginning when you open Chrome?duducrash wrote: ↑1 year agoIts on chrome for ios, I'm not logged on any other sites on the phone but I will check out.spacemonaut wrote: ↑1 year agoWhat browser are you using? Does this happen on other sites on that browser to which you're logged in?
(The latter would make me think something's clearing your cookies/etc when you close)
To the beaten, the broken, or the damned; the lost, and the wayward: wherever I may be, you will have a home.
When I open! It hasn't happened in the last few days thoughFeyd_Ruin wrote: ↑1 year agoDoes it do it while you're actively browsing, or does it seem like it just always does it at beginning when you open Chrome?duducrash wrote: ↑1 year agoIts on chrome for ios, I'm not logged on any other sites on the phone but I will check out.spacemonaut wrote: ↑1 year agoWhat browser are you using? Does this happen on other sites on that browser to which you're logged in?
(The latter would make me think something's clearing your cookies/etc when you close)