Authentication failures that don’t look like authentication failures #
When an authentication or session problem hits a WordPress site, the visible symptom is rarely “you are not authenticated.” It’s more often something that looks completely unrelated: a Checkout Button that does nothing, a form that submits but doesn’t process, an admin action that appears to run but doesn’t save, a login page that loads and immediately redirects back to itself. The connection between the symptom and the authentication layer underneath it is invisible from the front end.
Loupely captures authentication and session events from the server side to surface that connection.
What Loupely captures from authentication activity #
The server-side capture includes authentication-related events from the current request:
- nonce verification results (whether the security token attached to a form submission or Ajax Request was valid, expired, or missing)
- session state (whether the current user session is valid and consistent across the request)
- authentication failures in the WordPress authentication layer
- capability checks that failed (where WordPress tried to verify that a user has permission to perform an action and the check failed)
The nonce: what it is and why it fails #
WordPress generates a nonce (a one-time security token) for almost every form, Ajax Request, and admin action on the site. When the action is submitted, WordPress checks the nonce to confirm the request is legitimate and hasn’t been tampered with. If the nonce doesn’t match, the action is rejected.
Nonce failures are one of the most common causes of form submissions and checkout actions that appear to run but silently fail. They happen for several reasons:
- Cached pages serving stale nonces. Caching plugins store a snapshot of a page including its nonces. If the cached page is served to a user hours after it was cached, the nonce in that page has expired. The user submits the form, the nonce check fails, and nothing happens. No error message. Just silence.
- Clock skew between the server and a CDN or proxy. Nonces are generated and validated based on server time. If a CDN or reverse proxy has a different timestamp than the origin server, nonces can fail validation even when they’re fresh.
- A caching plugin caching the login page. If the login page itself gets cached, users get logged in on a cached session token rather than a fresh one. Session state becomes inconsistent and actions that require a valid logged-in state silently fail.
- Security plugin interference. Some security plugins aggressively rotate or invalidate nonces as a hardening measure. If the rotation interval is shorter than the user’s session, they’re operating on expired security tokens without knowing it.
Session failures #
Session failures are distinct from nonce failures but often occur together. A WordPress user session stores the logged-in state across page loads using a combination of a browser cookie and a server-side token. Session failures occur when those 2 things get out of sync: the browser has a cookie that says the user is logged in, but the server no longer has a valid corresponding token, or the server’s token and the browser’s cookie are for different sessions.
The most common causes: a security plugin that forcibly expires sessions, a site migration that transferred the database but not the authentication salts in wp-config.php, or a misconfigured object cache (Redis or Memcached) that’s serving stale session data.
What the diagnosis looks like for authentication failures #
When Loupely identifies a nonce or session failure, the diagnosis names which specific authentication check failed, what likely caused it, and which caching or security layer is the most probable source. The triage step is usually a cache clear (for nonce failures caused by stale pages), a security plugin configuration review, or, for session failures after a migration, a walkthrough for regenerating authentication salts.