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 themm-loginaction). If the nonce is missing or invalid, login is rejected vor credentials are ever checked (wp_signon()is never called).
It is nicht 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
- Gehe zu MemberMouse → WordPress Settings → Login Page.
- Siehe “Use the WP nonce validation for login.”
- Save.
No other configuration is required for standard MemberMouse login forms.
Caveats & edge cases (read before enabling)
- The nonce field rides with the password field.
The hidden nonce is emitted inside thePasswortcase 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. - 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. - 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.) - Scope. This protects MemberMouse's AJAX login endpoint (
module-handle→MM_LoginFormView). It does nicht alter WordPress's ownwp-login.php. - 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)
| Message | Cause |
|---|---|
Invalid request parameters. | Die 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). |

