Tomevexa Secure Login

[tomevexa_secure_login redirect_url="https://example.com/account/"]

Changelog

1.3.25

• Fix interpolated i18n placeholders in password-renewal emails and prepare inactive-profile count and row queries directly.
• Document the read-only login-screen flags and trusted AIOS table identifier used for WordPress 5.8 compatibility.
• Align the description, FAQ, privacy information, and upgrade guidance with the current PHP and JavaScript behavior, including email-first device-passkey login.
• Document dedicated page slugs, optional integrations, reminder limits, and the scope of third-party authentication checks.
• Refresh the plugin directory icon with matching 128px and 256px assets.
• Add an explicit uninstall data-retention choice. Preserve data by default; remove plugin settings, user metadata and database transients only when permanent cleanup was selected. Stop the reminder schedule in both cases.

1.3.24

• Resolves WordPress.org Plugin Check i18n, input-sanitization, naming, and database-query notices.
• Adds WordPress.org icon assets for the plugin listing.
• Keeps the existing authentication behavior while tightening code-quality annotations and query construction.

1.3.23

• Clear the login form fields when a page is entered or left, including back-forward browser restoration, to avoid reusing an old visible entry.
• Remove Tomevexa’s password verification cookie on WordPress logout; retain standard browser password manager behavior.

1.3.22

• Detect an exact duplicate email in the Tomevexa form and explain it without submitting a password attempt.
• Reject repeated email input on the AJAX endpoint before AIOS failed-login reporting and record a short-lived diagnostic reason for administrators.

1.3.21

• Display the Profile Builder password recovery and new-password steps in a simple, accessible page without the theme header or skip-link focus handlers.
• Retain the original Profile Builder shortcode, its validation and submit behavior, plus WordPress head and footer hooks for its assets and integrations.

1.3.20

• Improve Profile Builder registration labels for the phone number and biography, the password visibility button, and mobile input autofill hints.
• Give the public registration and password reset forms visible focus and touch sized controls while retaining Profile Builder’s native submission and validation.

1.3.19

• Send visitors from the WooCommerce account landing page to the shared Tomevexa login; after authentication, apply Profile Builder role redirects before the requested account destination.
• Apply account approval and existing AIOS IP locks to email-code and passkey sign-ins as well as password sign-ins.
• Give passkey sign-ins the same Profile Builder redirect path used by password and email-code sign-ins.

1.3.18

• Apply existing AIOS network lockouts to every password attempt through Tomevexa, including approved members.
• Notify the standard WordPress failed-login hook when the email is unknown or the password is wrong, so AIOS can receive these attempts from the Tomevexa form.

1.3.17

• Give the email-code request, code confirmation, and password buttons separate native button click actions for VoiceOver; Enter in the code or password field invokes the matching action.
• Remove forced focus changes after sending a code, allowing the screen reader to remain on its chosen control.
• Keep AIOS network lockouts on the administrator password path; member login uses Tomevexa’s own rate limits and adaptive email code, so a lock from the renamed WordPress login cannot block a valid member on the dedicated route.
• Keep the public login link and administrator login guidance introduced in 1.3.16.

1.3.16

• Point public WordPress login links to the dedicated Tomevexa form while retaining administrator and forced reauthentication paths.
• Add an accessible link to the member login above the renamed WordPress administrator login form, including after an error.
• Leave the administrator form and its security controls available; the new link guides members to the separate form.

1.3.15

• Route logged-out visitors on the WooCommerce account landing page to the single Tomevexa login form.
• Return those visitors to the account page after login, preserving WooCommerce account features and password-reset endpoints.
• Leave WooCommerce itself and checkout behavior unchanged.

1.3.14

• Fetch a fresh public login nonce for each authentication request, avoiding expired page-cache copies.
• Clear a rejected password field and explain how to replace an outdated browser-saved password.
• Show administrators the last 24-hour password-login outcome for a supplied email: unknown email, password mismatch, security lock, pending approval, or other authentication refusal.
• Keep separate timestamps for the last rejected attempt and last verified password so a successful administrator test does not erase the user’s failure diagnosis.
• Store only short-lived reason codes under salted email hashes; never record passwords or their hashes.

1.3.13

• After confirming a correct password, report Profile Builder accounts awaiting approval separately from invalid credentials.
• Preserve Profile Builder approval checks and keep the account state private from callers with an incorrect password.
• Clear Tomevexa’s failed-password counters for an approved-password submission awaiting account review.
• Respect active All-In-One Security network lockouts on the custom AJAX password form and announce the local retry time instead of treating the lock as a wrong password.

1.3.12

• Render shortcode-only login pages in an isolated document for logged-out visitors, without theme scripts or modal focus handlers.
• Keep the site’s ordinary theme on other pages and on the passkey management view after login.
• Let the email keyboard’s Return key move into the password field rather than implicitly submitting the first action.
• Stop removing the consent dialog with JavaScript after it has initialized.

1.3.11

• Record completed password resets and password changes made from the user profile when calculating expiry.
• Permit a correct password to clear an earlier failed-attempt block immediately after a reset.
• Distinguish a correct password rejected by another authentication check from invalid credentials.
• Preserve the VoiceOver editing cursor on field errors and remove the competing submit-button mutation observer.

1.3.10

• Quando la coppia email/IP raggiunge il limite di tentativi errati, il modulo avvisa immediatamente l’utente e mostra in orario del sito l’inizio e la fine della finestra di 15 minuti.

1.3.9

• Il messaggio dopo una password corretta da una rete non ancora attendibile spiega la verifica tramite codice email e mostra la durata configurata della fiducia per quella rete.

1.3.8

• L’elenco inattivi usa anche i timestamp già presenti di WP Last Login e considera la data più recente tra ultimo accesso e attività autenticata. Valori assenti, vuoti e zero restano nella scheda attività sconosciuta.

1.3.7

• Registra l’ultima attività autenticata (al massimo una scrittura al giorno per utente) e mostra in Utenti, e nel menu Profile Builder quando disponibile, l’elenco paginato dei profili inattivi da oltre 12 mesi.
• I profili senza attività registrata restano in una scheda separata: lo storico precedente all’installazione non è ricostruibile e nessun profilo viene cancellato automaticamente.

1.3.6

• I blocchi per credenziali errate sono limitati alla coppia email/IP (8 errori in 15 minuti); la soglia IP segnala all’amministratore un’anomalia della rete condivisa senza bloccare gli altri account.
• Invio di un promemoria per rinnovare la password nei sette giorni precedenti la scadenza o dopo la scadenza, una volta per ciclo password. La pianificazione usa WP-Cron e richiede traffico al sito o un cron di sistema configurato.
• Nelle impostazioni sono mostrati gli ultimi 100 utenti e l’esito disponibile dell’email: codice verificato, invio accettato o invio fallito. L’invio accettato non dimostra la consegna; per riconoscere indirizzi abbandonati servono gli eventi di rimbalzo del provider email.

1.3.5

• Bind password-expiry session state to the newly issued WordPress session token after login, including standard WordPress password sign-ins.

1.3.4

• Proposes the IP from the most recent failed password attempt when an administrator looks up an email; it expires after 15 minutes.
• Shows recent account and IP lockout alerts in the plugin settings, with an archive control and automatic expiry within 24 hours.
• Updates the privacy description for the temporary troubleshooting data.

1.3.3

• Added configurable failed-password thresholds for each account and IP in Settings → Tomevexa Secure Login.
• Added an administrator-only lookup and reset for a specified email or IP, with a nonce and automatic expiry information.

1.3.2

• Count only failed password checks toward the per-account and shared-IP login limits; successful logins no longer lock out other users on the same network.
• Explain when a valid password requires a reset or an additional email code, and report an email-code transport failure after a successful password check.
• Includes the 1.3.1 login order and email autocomplete changes.

1.3.1

• Ordered the login choices as password, temporary-code continuation, and passkey, followed by the temporary-code verification controls.
• Marked the account email field as the username for password managers and added iOS email-entry hints without changing its native email input type.

1.3.0

• Kept the temporary-code and password controls in the accessibility tree from initial page load instead of revealing them dynamically.
• Removed the password disclosure control so VoiceOver can reach the native password field directly.
• Preserved a linear email, temporary-code, password, and passkey reading order for iOS VoiceOver without Screen Recognition.

1.2.9

• Restored the submit type after legacy page snippets rewrite the login buttons during DOMContentLoaded.
• Added a guard for the three primary login actions so VoiceOver activation remains reliable even if an external snippet changes native submit semantics again.

1.2.8

• Made the current authentication action submit the form so VoiceOver users can use the Return/Go key while editing email, code, or password fields.
• Delayed OTP field disclosure and focus until the code request succeeds, avoiding duplicate focus changes and virtual-cursor interruptions.
• Made password and temporary-code modes mutually exclusive and exposed the current disclosure state consistently.
• Added explicit, associated error feedback when passkey login is requested without a valid email address.
• Consolidated passkey login into the main interaction controller to prevent competing click and live-region updates.
• Replaced the non-modal passkey-choice dialog semantics with a labelled region matching its inline behavior.
• Kept the email field enabled when passkey is the only configured authentication method.

1.2.7

• Removed the synthetic touch, click, and focus-redirection handlers from the email, temporary-code, and password inputs so VoiceOver can activate the native controls directly.
• Removed the WebAuthn autocomplete token from the email field; passkey login remains available through its dedicated button.
• Suppressed the modal Complianz cookie banner on the dedicated login page because its focus trap could prevent VoiceOver from reaching the form and redirect focus to “Vai al contenuto”.
• Non-essential cookies remain blocked by Complianz until the visitor gives consent elsewhere on the site.

1.2.6

• Removed redundant aria-describedby associations and hidden helper descriptions that VoiceOver announced repeatedly.
• Simplified field labels to “Inserisci la tua mail”, “Inserisci il codice temporaneo”, and “Inserisci la password”.
• Each action button now exposes only one concise accessible name.
• Removed bulk dialog descriptions so its explanatory paragraphs are encountered once in normal reading order.
• Added cleanup for descriptions injected by legacy WPCode login-accessibility snippets.
• Extended the VoiceOver skip-link focus safeguard to the email, temporary-code, and password fields.

1.2.5

• Reordered the login form into a single predictable vertical sequence for VoiceOver, JAWS, NVDA, keyboard users, and low-vision users.
• The controls now appear as Continue, password-panel opener, password confirmation, and passkey login; revealed fields remain adjacent to the control that opened them.
• Added a native password visibility control with “Mostra password” and “Nascondi password” states.
• Added explicit screen-reader descriptions for every authentication action.
• Temporary-code and password fields receive focus as soon as they are revealed, using the numeric or password keyboard configured by the device.
• Removed decorative “or” separators that interrupted linear screen-reader navigation.
• Added label normalization so legacy WPCode accessibility snippets cannot overwrite the new button names.

1.2.4

• Fixed passkey creation immediately after password or email-code login.
• The passkey-registration nonce is now requested only after the browser has accepted the new WordPress login cookie, so it is bound to the active session token.
• Added a dedicated authenticated setup-context endpoint with HTTPS and feature-state checks.

1.2.3

• Replaced the automatic passkey-setup redirect with an explicit post-authentication choice.
• Users without a passkey receive an accessible explanation and can choose either “Sì, crea una passkey” or “No, continua senza passkey”.
• Choosing Yes opens the current device’s native Windows Hello, PIN, Face ID, Touch ID, or Android biometric registration prompt before completing the redirect.
• Choosing No completes login and remembers the decision in that browser until its site data are cleared.
• Added screen-reader descriptions, focus management, and assertive status announcements for JAWS, NVDA, and VoiceOver.
• Added a targeted iPhone VoiceOver focus safeguard for the email field to prevent an unintended jump to the page’s “Vai al contenuto” link.

1.2.2

• Added a front-end passkey manager through the [tomevexa_passkeys] shortcode.
• Logged-in users who revisit a page containing [tomevexa_secure_login] now see the passkey setup interface instead of a generic already-logged-in message.
• After a successful password or email-code login, users without a passkey are returned automatically to the setup interface.
• Users can register the current device with Windows Hello, device PIN, Face ID, Touch ID, or Android biometrics without access to the WordPress administration area.
• The front-end manager also lists and removes registered passkeys and keeps USB/NFC security-key registration as a separate explicit choice.

1.2.1

• Passkey login now uses the email address to request only the account’s registered on-device credentials, preferring Windows Hello, Face ID, Touch ID, Android biometrics, or the device PIN instead of QR, USB, or NFC flows.
• Stored authenticator transports are now retained for new passkeys; existing on-device passkeys remain compatible.
• Passkey verification now supports targeted authentication responses where userHandle is omitted, while binding the challenge to the expected WordPress user.
• Password login now validates the WordPress password without being converted into a generic failure by an unrelated global 2FA challenge; Tomevexa’s own adaptive email step-up remains enforced.
• Successful password authentication clears the plugin’s failed-attempt counters.
• Improved iPhone VoiceOver behavior for the email field by avoiding native validation focus jumps and preserving focus during activation.

1.2.0

• Added accessible administrative controls to enable or disable email OTP, passkey, and password login independently.
• Prevented administrators from disabling every login method; password login is restored automatically when no method is selected.
• Disabled authentication endpoints now reject direct requests as well as hiding their front-end controls.
• Disabling email OTP also disables email-based adaptive step-up verification.
• Verified the Italian login page with a 100/100 mobile accessibility audit.

1.1.1

• Added a dedicated on-device passkey registration path for Windows Hello, Windows PIN, Face ID, Touch ID, and Android device verification.
• Added a separate security-key registration choice so USB/NFC authenticators remain available.
• Passkey sign-in now prefers the current device while retaining hybrid and security-key alternatives.
• Kept the existing Italian front-end login form and localized the passkey profile controls in Italian.

1.1.0

• Added local WebAuthn/FIDO2 passkeys with usernameless passwordless sign-in.
• Added passkey registration and removal in the WordPress user profile.
• Requires HTTPS for passkey operations and user verification (PIN/biometric/device verification).
• Passkey authentication verifies RP ID, origin, challenge, user presence, user verification, ES256 signatures, and authenticator counters.

1.0.0

• Initial Tomevexa Secure Login release.
• Added accessible email OTP authentication for non-administrator users.
• Added optional password login and configurable password expiry.
• Added local adaptive step-up verification for password logins from networks that have not yet been trusted.
• Added privacy-preserving trusted-network recognition using salted hashes of reduced network prefixes with configurable expiry.
• Added layered rate limiting, attempt limits, hashed OTP storage, and generic code-request responses.
• Added optional Profile Builder Pro custom-redirect compatibility.
• Prepared all user-facing strings for translation through WordPress.org.