v5.2 nonce/cookie issue causing repeated logouts

[blakmarkit]

Checklist

• I have looked into the Readme and the documentation, and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

I've been running into an issue since migrating to v5—when the Auth0 v5 plugin is activated, Application Configuration (under "Options") is correct (and saved), and "Enable Authentication" is set to "Enabled", I am repeatedly losing the logged-in state and getting kicked back to the wp-login/Universal Login screen. Whenever I try to edit a page in my frontend editor (Bricks, see additional context), or do any administrative task, I'm logged out. I'm not even able to edit the Auth0 settings to revert "Enabled" to "Disabled" without getting logged out.

Most of the Auth0 plugin's settings are left at default, currently. My presumption is that the problem is in the "Advanced" section of the options—there isn't any clarity on which settings would need to change. "Pair Sessions" is "Enabled for Non-Administators" (which I believe is default)—and all the rest are unchanged. I'm pretty savvy when it comes to troubleshooting, but there's just no documentation that I've been able to find that explains what's happening.

I've tested this on my host's dev environment, as well as on a fresh Local install. It's happening on both environments.

Reproduction

• Install Auth0 v5
• Activate plugin
• Enter Application Configuration details
• Save
• Enable Authentication

Additional context

Bricks builder theme + child theme
tested 1.9.7.1 & 1.9.8-beta

wp-auth0 version

5.2.0

WordPress version

6.5.2

PHP version

8.2.14

[evansims]

Hi @blakmarkit, very sorry to hear you're facing some challenges there. Let's see if we can figure out what's going on.

So, testing things locally here, I've not been able recreate this issue on my end thus far. Since you mentioned also encountering this out-of-the-box with a fresh plugin configuration, it sounds like there is a conflict with the WP/environment configuration or potentially another plugin interfering.

Offhand, it sounds like your session is being repeatedly invalidated for some reason.

Could you please:

• Use your browser's developer tools console to see if any cookie errors are being reported?
• Use your browser's developer tools network monitor to track how your cookies are manipulated during page transitions? Do you notice any cookies being deleted after authenticating?
• Check your PHP logs to see if any exceptions might be getting thrown in the background that we're not seeing live?
• Check if any other plugins aside from 'Bricks' are installed?

I've tested this on my host's dev environment, as well as on a fresh Local install.

By fresh local install do you mean starting from a completely fresh local WP install, or do you mean a fresh plugin install on an existing local WP installation?

If the latter is the case, could you try botting up a fresh local WP install, installing only this plugin, and see if it at least works that far? That would help us narrow down if it's an environment or plugin conflict of some kind.

[blakmarkit]

@evansims yes, clean fresh WP 6.5.2 in Local (PHP 8.2.10, nginx, MySQL 8.0.16). I did it a second time to make sure, because the other time I installed Query Monitor and maybe three other plugins that were never activated (I installed just a few of what I thought would be likely culprits for conflict). Also, the first time I used Composer/wpackagist to install the theme + plugins, and the second time I did it more "traditionally" with manually uploading zips. I did set up a fresh zip installer—downloaded the repo source, ran composer, then zipped it.

No PHP errors happening. No other plugins or themes, just Bricks (which installs as a theme).

I can confirm that the conflict is between Bricks and Auth0. Changing to a default WP theme like TwentyTwentyFour doesn't cause the logout issue, which explains why it hasn't been replicable. That said, for both the default and Bricks theme activated, there are "Cookie check failed" 403 responses, though many more for Bricks. I've done some jamdev recordings to capture all of the actions and network traffic (supposedly sans secrets), but I'm not sure I'm comfortable posting them here. If there's another way to send them, I can do that.

I've been in contact in parallel with the Bricks support team, and while they haven't been able to pinpoint anything yet, either, perhaps they'd be willing to collaborate to solve the source of the issue? This feels like one of those problems that can land in limbo because it's not clear who is the best to address it. When we were on v4.x, we didn't have issues with Bricks + Auth0, so this appears to be something related to the v5 plugin revamp, rather than something that's specifically (or always) malfunctioning with Bricks. Downgrading isn't an option with our host—PHP 8.2 is the only choice, so rolling back won't work.

[blakmarkit]

From the Bricks team: "we're simply verifying nonces using the default WordPress wp_verify_nonce() function."

Is there any reason that would be a problem?

[blakmarkit]

@evansims Quick update from late last week—turns out I spoke too soon. I was getting the logout issue even with the default TwentyTwentyFour theme on my barebones local install, too. Tested again this morning after clearing cookies and still having the issue. Auth0 is the only plugin installed.

[XelNizar]

i am facing a similar problem while using the apiFetch (@WordPress js method) which is throwing an Cookie check failure/Cookie nonce invalid error and causing the user to logout.

[ariestav]

@evansims Can you confirm that you are able to reproduce this issue?

[evansims]

👋 Think I may have tracked down the cause for the issue you're seeing — can you grab a ZIP of the development branch, extract over your existing local install, and see if this resolves things on your end?

I believe the issue stems from rolling sessions enablement and changes in WP 6.5, which significantly increased the number of concurrent async calls to the backend API while inside the admin dashboard, especially the editor view.

Essentially, for rolling sessions to work, we have to "refresh" the WP authentication cookie to extend its expiration time. In previous WP versions, refreshing this cookie on each request worked fine — but due to the increased number of async backend API calls introduced in 6.5, you can now encounter a race condition where a backend request "refreshes" the authentication cookie's session ID (invalidating the previous one) before another already-in-flight request is resolved, causing it to fail. Subsequently, this results in an authentication state conflict, and for security reasons, WP invalidates all those sessions — forcing you to log back in.

I have made adjustments to throttle this cookie refresh, particularly in the case of backend API requests, to reduce the likelihood of this occurring.

Hopefully, this resolves the issue fully for you. Once you test it and confirm, let me know, and I'll release a full release with the fix. Apologies for the delay; this was admittedly a tricky one to track down, as it requires a very specific configuration and set of circumstances to manifest.

[jsincavage]

@evansims I have been running into similar situations with nonce verify causing issues. I believe the issue is with "Use Rolling Sessions" setting. This setting wasn't changing anything on our end. I believe I found the issue in
https://github.com/auth0/wordpress/blob/5.x/src/Actions/Authentication.php#L571

I changed
if ('false' !== $this->getPlugin()->getOption('authentication', 'rolling_sessions'))
to
if ('false' !== $this->getPlugin()->getOption('sessions', 'rolling_sessions'))

I believe 'rolling_sessions' is in group 'sessions' not 'authentication'. Now when we have "Use Rolling Session" set to "Disabled" we no longer get nonce issues. This seemed to fix the issue for us not sure if it will fix issues for others.

[evansims]

@jsincavage That's a good catch, thanks. I'll fix that in the next release. Disabling rolling sessions is a viable workaround until the fix (link above) is released: just waiting on confirmation that it fixes the problem for y'all. Details on the cause of the issue are in my previous post, above, but essentially WP 6.5 introduced an opportunity for an authentication race condition that can conflict with rolling sessions (when enabled.)

[blakmarkit]

@evansims Thanks for tracking that down. The explanation of what's happening makes sense. The latest code does appear to be working so far.

[evansims]

Thanks for confirming @blakmarkit I'll work on getting a new release out that contains the fix this week.