johnbillion/user-switching

Shop Managers getting 502 error on Switch To - Admins do not

Closed this issue · 13 comments

Hello - I'm sorry to say, I don't know what was updated recently, but the site is currently operating with all up-to-date plugins, and Woo Commerce Shop Managers trying to use User Switching is now failing with 502 Bad Gateway error. Server logs aren't showing anything obvious that I can say relates to these events.

FYI - Admin users can Switch To and it works perfectly still. This is only related to Shop Managers, who have been successfully using this feature for several weeks now, until the last couple days.

This is most likely an issue with your Nginx configuration: https://wordpress.org/support/topic/502-bad-gateway-36/

No - only because Admins can switch users perfectly fine. I'm going back and forth. This only occurs when the user is a Shop Manager when they go to switch. Admins can switch fine. Are you still saying it's NGINX config?

Also this is happening to three different people on different systems in different browsers. All can confirm - Admin users can switch just fine. Shop Managers could switch a few days ago. Now they cannot.

Is this a secondary switch? ie you switch to a user and then switch from that user to another? If so, that could well be triggering the 502 if your server has a low proxy header size limit because of the increased size of the cookies for secondary switches.

Did you reload Nginx after increasing the value of the proxy directives?

I'm having my server host up the limits as suggested, but I must apologize - there is another piece of info here. The secondary switch was only me, as admin, trying to be a Shop Manager, so my troubleshooting involved a secondary switch, but the initial problem does not. Instead, we now see that this only happens to Shop Managers for one (and counting) user record. I just learned that the client is switching all the time still, but this one user record triggers the error.

So we're upping the limits in case this particular user has some long string of metadata, but other than confirming and resaving the user record to fix any corruption, why would a particular target user being switched to, cause an issue like this?

Thanks - I'll report on the limit uppage.

Ok those limits were upped, cache cleared, new PC, new browser, and this one user continues to trigger the nginx error. And it instantly fails. I've recommended deleting the user and recreating their account, but unfortunately they have order history the client wants to preserve (only 5 orders though - nothing insane). I noticed an @ sign in their username but it's not their email address. Their nickname also has the @ sign. Otherwise, they appear to be a perfectly normal user record.

Can you ask them to clear all their cookies? If they've got existing junk cookies in their browser, this could be causing a problem.

I'm able to reproduce the error on my end. With entire browser wiped, all cookies, files, caches cleared, Shop Manager still cannot switch to this one user. Admins can. So it's not browser cookies.

I'm out of ideas then, I'm afraid. Your best bet is to contact your host and ask them for the specific error message that's causing the 502 and go from there. Make sure they've upped those proxy limits! :-)

Again, why would proxy limits have anything to do with this, if Admin users can switch to this user just fine? It's specific to Shop Manager, and only this one user. Shop Manager is switching to other users of the same roles with no issues. If you are not curious, then I'll drop it, but server config is really unlikely to be the issue and even if it was, my provider confirmed they met the specs by upping the settings to what was mentioned in the thread that you referenced. I'll ask them for an error log.

This plugin is 10 years old and every single time a 502 error has been reported it's because of a low proxy header size limit in place, so please don't dismiss the suggestions that I'm giving you.

If it turns out to be something else then yes I'm curious, but let's see what your host reports back first.

I never dismissed any of your suggestions. My web host recommended a different plugin - they may know of an incompatibility. View As plugin appears to be working OK - not sure what's different about their approach, but there you have it. Thanks for the help.