Rolling Sessions still causing nonce invalidation in plugin version 5.3.0

[dennis-n-dean]

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

Having Rolling Sessions enabled still appears to be causing nonce invalidation issues in plugin version 5.3.0.

With Rolling Sessions enabled:

• calls from the admin area/Gutenberg to wp-json return 403, making it impossible to edit featured images, category and tags, etc.
• things that rely on the heartbeat, like post check in/check out or taking over a post a colleague is editing break
• deleting posts, activating/deactivating plugins, etc. causes a "this link has expired" error

Disabling rolling sessions appears to fix all these problems (but I assume will cause problems of its own).

Reproduction

1. Install Auth0 plugin
2. Leave "Rolling Sessions" enabled
3. Observe

Additional context

No response

wp-auth0 version

5.3.0

WordPress version

6.8.1

PHP version

8.4

[kishore7snehil]

Hi @dennis-n-dean 👋 , thanks for the detailed repro steps.

To zero in on this, could you also share:

1. Any caching layers you have in front of WP (e.g. Varnish, Cloudflare, WP Super Cache, object cache, etc.)
2. A screenshot or HAR of one failing request in the admin/Gutenberg that shows the X-WP-Nonce header and the 403 response
3. A screenshot of your Auth0 plugin settings page, specifically which Rolling Sessions options you have toggled

Once we’ve got that, we can confirm if it’s purely the rolling-session cookie vs. nonce window mismatch or if another cache layer is exacerbating it—and then recommend the precise tweak. Thanks!

[dennis-n-dean]

Hi @kishore7snehil, finally getting a chance to circle back around to this.

It turns out turning off rolling sessions does create an issue. Every few weeks, a user who was previously logged into the site will hit a 500 error when trying to view the site (front end or wp-admin, as long as they were logged in).

It appears to happen when the WP session has ended but they still have an Auth0 session (or maybe vice verse).
Correction: it appears to happen when the Auth0 session has ended but they still have a wordpress_logged_in cookie.

This causes WP to get stuck in a loop, causing a memory exhaustion error, like:

2025/08/26 14:25:55 [error] 240#240: *1276763 FastCGI sent in stderr: "PHP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in [...]/public/wp-includes/option.php on line 615; PHP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in [...]/public/wp-includes/class-wp-fatal-error-handler.php on line 37" while reading response header from upstream, client: 198.[...], server: [...].org, request: "GET /wp.serviceworker HTTP/2.0", upstream: "fastcgi://unix:/var/run/php8.4-fpm-[...].sock:", host: "[...].org:21606", referrer: "https://[...].org/wp.serviceworker"

Instructing the user to clear their cookies fixes it and allows them to visit the site or the login page.

Back to the original issue – to answer your questions:

1. we use Cloudflare for caching, with our login page set to bypass. And our host has a built-in page cache (but that doesn't operate on the wp-admin area).

2. I don't have a screenshot at the moment since I've had rolling sessions turned off, but I can set up a dev environment to test it if turning rolling sessions on is going to be part of the solution to the above.

3. Screenshots attached.

Thank you!

[kishore7snehil]

Hi @dennis-n-dean,

Thanks for the detailed notes and screenshots.

Short answer: turning “Use Rolling Sessions” on won’t fix the 500/memory issue. It will likely bring back the nonce/403 problems in wp‑admin because WordPress nonces are tied to the auth cookie, and rolling sessions rotate that cookie frequently.

What’s happening is that with Pair Sessions set to Disabled, WordPress can keep a valid wordpress_logged_in cookie even after the Auth0 session ends. That mismatch can occasionally surface as the 500/memory exhaustion you saw. Turning rolling sessions on would just swap that problem for nonce failures in the editor and admin.

For now, please keep Rolling Sessions off. You can keep Pair Sessions as you prefer, just note it allows the WP session to outlive the Auth0 session by design. Also make sure your CDN/cache bypass covers the login and admin/API routes, including wp-admin, wp-login.php, wp-json, wp-admin/admin-ajax.php, and the service worker path you saw in logs.

If the 500 happens again, could you share the exact route that triggered it, a few lines of the PHP stack just before the fatal in wp-includes/option.php, and which cookies were present on that request? If it helps, I can share a tiny mu‑plugin to log out stale WP sessions when there isn’t an Auth0 session - purely as a temporary safety net without changing your settings.

Thanks again for the thorough context.

[goldenapples]

I've run into the same issue on v5.5.0, and tracked the problem down to the call to wp_set_auth_cookie() in the shutdown hook here. Doing this invalidates all nonces which will be localized in scripts or wp_nonce_url calls when generating the page.

It looks like this shutdown function is only intended to extend the login and auth cookies' lifetime. You should be able to do the same thing without issuing a new token by passing the existing token into wp_set_auth_cookie() - though you'll also have to extend the token expiration date server-side to make sure it doesn't expire.

I opened #948, which I think should address these issues.