ShivWeb Login Verification
ShivWeb Login Verification
Description
ShivWeb Login Verification adds a second step after a normal password login: the session is held until the user enters a code emailed to them. It is enforced server side across the front end, wp-admin, REST and AJAX, and it never touches wp-login.php or the WooCommerce login forms, so it works the same on wp-login.php, WooCommerce My Account, and both the classic and the block checkout.
This is “password plus email verification”, a two-step login. Email codes prove ownership of the mailbox; they are not an independent second factor in the strict sense, and the plugin never claims to be bank-grade 2FA.
Highlights
- Email OTP after login. The password is still required.
- Per-role enforcement, defaulting to the Customer role only.
- Enforcement is off until you enable it, and enabling requires a delivered and entered test code, so a broken mailer can never lock everyone out.
- Trusted devices: remember a browser for a number of days you choose.
- WooCommerce block checkout aware: the Store API is blocked for unverified sessions and the shopper is guided to the code screen.
- Optional email verification at registration, with daily cleanup of abandoned unverified accounts.
- Rate limiting on every layer: resend cooldown, per-session limits, lockout, and a per-account hourly send cap.
- No external services, no account, no tracking, no logs. Email goes through wp_mail(), so your SMTP plugin handles delivery.
Recovery
If you ever lock yourself out, add define( 'SWLV_DISABLE_OTP', true ); to wp-config.php, or run wp swlv disable with WP-CLI. Both release every held session immediately. To unstick a single user (send limit reached, mailbox typo), run wp swlv reset-user <id|login|email>.
Installation
- Install and activate the plugin. Nothing is enforced yet.
- Go to Settings, then Email Verification.
- Choose the roles that should verify, send yourself a test code, enter it, tick “Require a code at login”, and save.
Faq
Yes. The block checkout logs customers in over the Store API, which the plugin refuses for unverified sessions, and a small script guides the shopper to the verification screen.
No. All email goes through wp_mail(). Use any SMTP plugin you like for reliable delivery.
Affected users cannot verify, but you can always recover with the wp-config.php constant or WP-CLI, both documented above. Administrators are not gated by default.
Strictly speaking, no. An emailed code proves control of the mailbox, which is a second step, not a fully independent second factor. It still stops anyone who only has the password.
Check the spam folder first. The screen lets you request a new code after a short cooldown. If nothing arrives at all, the site’s email delivery is the usual cause: the site owner can go to Settings, then Email Verification, and send themselves a test code. If that fails too, install an SMTP plugin and test again. A single stuck user can always be released with wp swlv reset-user.
Three things are expected behavior here. Sessions that were already logged in before you enabled enforcement are never challenged, only new logins are. A browser remembered through “Trust this device” skips the code until the trust expires. And only the roles you ticked are gated, so check the role of the account you are testing with, and note that administrators are not gated by default.
Codes are never stored, not even hashed alone: only keyed hashes live inside the WordPress session record, and they disappear when the session ends. Beyond that the plugin keeps one settings option, per-user send counters and trusted-device hashes in user meta, short-lived self-expiring transients for registration challenges and rate limits, and one cookie for “Trust this device”. There are no external services and nothing leaves your site. Uninstalling removes all of it. On shared computers, leave “Trust this device” unticked.
Reviews
Changelog
1.0.0
- Initial release.