WP Nonce Validation for Login

Setting location: MemberMouse → WordPress Settings → Login Page → “Use the WP nonce validation for login.”

When enabled, a login submitted through the MemberMouse login form is rejected unless it carries a valid WordPress nonce.


This checkbox turns on CSRF (cross-site request forgery) protection for the MemberMouse front-end login form.

  • OFF (default): the login AJAX request is processed without checking a nonce.
  • ON: the login AJAX request must include a valid WordPress nonce (mm-security, tied to the mm-login action). If the nonce is missing or invalid, login is rejected before credentials are ever checked (wp_signon() is never called).

It is not brute-force protection, rate-limiting, or a CAPTCHA. It only ensures the login POST originated from a MemberMouse-rendered login form on this site, not a forged/cross-origin request.


Why it matters

Without nonce validation, MemberMouse's login endpoint will accept a login POST from anywhere — including a form on a malicious third-party page that auto-submits credentials to your site (a classic CSRF vector, and a vector for some automated login-abuse tooling that posts directly to the endpoint).

A WordPress nonce is a short-lived, per-action token embedded in the form when WordPress renders it. Because an attacker on another origin can't read the freshly-generated token out of your page, requiring a valid nonce means the request must have come from a real, recently-served MemberMouse login form. Enabling this hardens the login endpoint at essentially zero cost to legitimate users.


How to turn it on

  1. Go to MemberMouse → WordPress Settings → Login Page.
  2. Check “Use the WP nonce validation for login.”
  3. Save.

No other configuration is required for standard MemberMouse login forms.


Caveats & edge cases (read before enabling)

  1. The nonce field rides with the password field.
    The hidden nonce is emitted inside the password case of the [MM_Form_Field] smart tag (class.loginform.php:177). A customized login form template that omits the password field smart tag will not render the nonce — and with the setting ON, every login attempt would then fail with “Invalid request parameters.” Standard/default forms include the password field, so they are unaffected.
  2. Full-page caching of the login page.
    WordPress nonces are time-limited (valid ~12–24 hours) and are regenerated per page render. If your login page is served from a full-page cache (caching plugin/CDN caching the logged-out HTML), visitors can receive a stale nonce, causing “Invalid nonce.” errors. Exclude the login page from full-page caching, or don't cache the logged-out form, when this setting is on.
  3. Page left open a long time.
    A login page left open past the nonce lifetime (>~24h) will fail validation on submit. The user simply refreshes the page to get a fresh nonce. (Normal nonce behavior.)
  4. Scope. This protects MemberMouse's AJAX login endpoint (module-handleMM_LoginFormView). It does not alter WordPress's own wp-login.php.
  5. Naming note. The stored option key is mm-option-use-mm-nonce-validation (internal “mm-nonce” naming) even though the UI label says “WP nonce validation.” It does use WordPress's native nonce API (wp_nonce_field / wp_verify_nonce).

Error messages a user might see (when ON)

MessageCause
Invalid request parameters.The mm-security nonce field was not present in the POST (e.g., custom form missing the password field, or a forged request).
Invalid nonce.A nonce was sent but failed wp_verify_nonce (expired, cached/stale page, or forged/invalid token).
Was this article helpful?

Related Articles

Can’t find the answer you’re looking for?

Reach out to our Customer Success Team
Contact us!