| 开发者 | portalelibri |
|---|---|
| 更新时间 | 2026年10月2日 19:54 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
random_int() and stored only as WordPress password hashes in temporary transients.[tomevexa_passkeys] and an optional device-passkey setup invitation after password or email-code login.[tomevexa_secure_login] shortcode on a page. You can optionally set a redirect destination:
[tomevexa_secure_login redirect_url="https://example.com/account/"]
The redirect is validated with WordPress redirect-safety functions. If a redirect_to parameter is supplied by WordPress, the plugin can also honor that safe destination.
Email delivery
OTP messages are sent with the standard WordPress wp_mail() function. Actual delivery therefore depends on the site's WordPress mail configuration and hosting environment. The plugin does not connect directly to an external email service.
Profile Builder compatibility
Profile Builder is not required. When Profile Builder Pro is active and its Custom Redirects module is enabled, Tomevexa Secure Login preserves the configured after-login redirect.
Accessibility
The login form uses semantic labels and buttons, keyboard-operable controls, visible focus indicators, polite and assertive live regions for status and errors, a single numeric OTP field compatible with paste and autocomplete="one-time-code", and reduced-motion support.
Accessibility also depends on the active theme and surrounding page content. Site owners should test the completed page with keyboard navigation and their preferred assistive technologies.
Privacy
Tomevexa Secure Login does not include analytics, telemetry, advertising, or direct third-party API requests. Passkey registration and verification are performed locally between the browser/authenticator and the WordPress site using WebAuthn; no external authentication service is required. OTP emails are sent through the site's configured WordPress mail system. Temporary OTP data is stored in WordPress transients and contains a password hash of the OTP, the user ID, expiry time, and attempt count. The OTP itself is not stored in plaintext. When adaptive step-up is enabled, trusted-network recognition stores only salted HMAC hashes derived from reduced network prefixes plus their expiry times in user metadata; the trusted-network list does not store raw IP addresses. For administrator troubleshooting, the latest IP used with an email after a failed password attempt is stored in a transient for 15 minutes. Login result reason codes, keyed by a salted email HMAC, are retained for up to 24 hours. Up to 20 block alerts containing the attempted email and IP are stored for at most 24 hours or until an administrator archives them. The plugin also stores the last observed authenticated activity timestamp in user metadata, updated at most once per day, and the most recent email send/OTP verification status for administrator review. The plugin-owned user metadata and settings are retained on uninstall by default. Administrators can instead save the permanent-cleanup choice before deleting the plugin; that choice removes the settings, six plugin-owned user metadata types, and plugin-owned database transients. Short-lived diagnostics and challenges use WordPress transients and expire according to their configured lifetimes. The browser stores a localStorage preference, keyed by an encoded email address, when the user dismisses the passkey setup invitation; clearing the site data removes that preference.
tomevexa-secure-login folder to /wp-content/plugins/, or install the ZIP file from the WordPress Plugins screen.[tomevexa_secure_login] to the page that should provide the login form.[tomevexa_passkeys].effettua-il-login with exactly [tomevexa_secure_login] as its page content. This enables the dedicated login route used by public login links and the WooCommerce account landing-page integration.registrati and resetta-password page slugs. The isolated password-recovery page is enabled only when the wppb-recover-password shortcode is available.No. Tomevexa Secure Login works with standard WordPress users. Profile Builder Pro integration is limited to preserving its optional custom after-login redirect when available.
No. Administrator accounts are deliberately excluded from the OTP path and from password-expiry enforcement. They can continue to use standard WordPress password authentication.
No. Passkey registration and authentication use the browser WebAuthn API and are verified locally by the WordPress site. HTTPS and PHP OpenSSL support are required. Private keys and biometric data remain on the user device.
While logged in, open your WordPress user Profile and find the Passkey Tomevexa section. Select Registra questo dispositivo for Windows Hello, Windows PIN, Face ID, Touch ID, or Android device verification. Select Registra una chiave di sicurezza for a USB/NFC security key. Passkey registration requires HTTPS, PHP OpenSSL support, and a WebAuthn-capable browser/authenticator. Up to 10 passkeys can be registered for one WordPress account. The current front-end login asks for the account email and requests internal device authenticators; USB/NFC and hybrid QR-code sign-in are not offered by this flow.
The authenticator keeps the private key. WordPress stores the credential identifier and public-key material required to verify future sign-ins, together with the authenticator counter and timestamps. The plugin does not receive or store biometric data.
Yes. The administrator exclusion applies to the email OTP path and password-expiry enforcement. An administrator may register and use a passkey from the WordPress user profile.
The existing WordPress password login remains available. Eligible non-administrator users can also use the plugin email OTP flow. Site owners should keep an appropriate recovery method available for privileged accounts.
When enabled, a non-administrator who enters the correct password from a network that has not yet been trusted must also enter an email OTP. After successful OTP verification, a salted hash representing that network can be trusted for the configured period.
The trusted-network list does not store raw IP addresses. The plugin reduces the current address to an IPv4 /24 or IPv6 /64 network prefix and stores a salted HMAC hash of that prefix. The web server and other WordPress components may still process or log IP addresses independently of this plugin.
No. The generated code is hashed with WordPress password-hashing functions before temporary storage.
A non-administrator who attempts password authentication with an expired password is directed to reset it. Email OTP login remains available. Set password expiry to 0 in the plugin settings to disable this feature.
No. It uses WordPress wp_mail(). Delivery depends on the site's mail configuration, hosting environment, and any SMTP or mail-delivery plugin in use.
Existing plugin settings, trusted-network metadata, and passkey public keys use the same storage names. New method switches default to enabled when absent from older settings. The current passkey login is email-first and requests the device authenticator, so an external security key registered in 1.1.0 is retained but is not offered by the current front-end login. Users can register a device passkey after signing in with another enabled method.
A logged-out page containing exactly [tomevexa_secure_login] uses the isolated login template. A shortcode with attributes or additional content keeps the normal theme template. Public login links and the WooCommerce account landing page use the dedicated route only when effettua-il-login contains the exact shortcode. The resetta-password page uses the isolated recovery template when Profile Builder recovery is available; registrati and resetta-password receive the Profile Builder accessibility enhancements.
The isolated login page outputs only the plugin assets and does not run the normal theme wp_head/wp_footer hooks. Theme navigation, consent banners, and other plugin scripts may therefore be absent on that page. Check required integrations before enabling this route.
Do not assume so. Tomevexa provides its own authentication endpoints. Its password endpoint calls wp_authenticate_username_password, which runs wp_authenticate_user checks, rather than the complete global authenticate filter chain. Email-code and passkey endpoints use their own identity verification. Profile Builder approval and existing AIOS lockouts are checked explicitly. Verify any separate 2FA or access-policy integration; use the standard WordPress login when that integration is required.
Users > Profili inattivi shows profiles inactive for more than 12 months and profiles with unknown activity, with 50 entries per page. It uses the newer valid timestamp from Tomevexa authenticated activity and WP Last Login. A missing timestamp does not prove inactivity, and inactivity does not prove that an email address is abandoned.
An accepted wp_mail() call does not prove delivery. A successfully verified OTP proves access to the mailbox at that moment. The settings page shows the latest status for the 100 newest users. Daily WP-Cron reminders target non-administrators with a recorded password-change timestamp when renewal is due within seven days or overdue. Each timestamp is attempted once, including failed sends, with a maximum of 100 reminder attempts per run; users without that timestamp are not selected. WP-Cron execution depends on the site's cron configuration.
Yes. Before deactivating and deleting the plugin, open Settings > Tomevexa Secure Login > Dati alla disinstallazione, or follow the Dati alla disinstallazione link in the active plugin row. Select either Conserva i dati per una futura reinstallazione or Elimina definitivamente tutti i dati del plugin, then save. WordPress runs uninstall without an interactive plugin prompt, so this choice must be saved first. Keeping data is the default, including upgrades from versions without this setting. Deactivation always keeps the data. Deletion always stops the reminder schedule. If permanent cleanup was chosen, deletion removes the plugin settings, passkey public credentials, trusted-network records, password-change and reminder timestamps, email status, observed activity, OTP and challenge transients, diagnostic counters, and block alerts stored in the WordPress database. Accounts, passwords, WP Last Login history, AIOS data, and Profile Builder data are preserved. Passkeys will need to be registered again after permanent cleanup. Existing credential data on the authenticator itself are not deleted remotely. Dynamic transients held by an external object cache expire at their original TTL; the plugin does not flush a shared cache. Browser localStorage preferences and cookies are outside the WordPress database; users can clear them through browser site-data controls. The cleanup operates on the current site's option table and plugin-owned user metadata; a network-wide multisite cleanup has not been validated.
aria-describedby associations and hidden helper descriptions that VoiceOver announced repeatedly.[tomevexa_passkeys] shortcode.[tomevexa_secure_login] now see the passkey setup interface instead of a generic already-logged-in message.userHandle is omitted, while binding the challenge to the expected WordPress user.