devteamzeal
Forum Replies Created
-
We have double checked the timezone on the server, website, and device(s) to ensure consistency and we can confirm that when testing for both UTC and GMT, the server, website and device(s) all report the exact same time, however the code still does not work when using an authenticator app.
It’s worth re-iterating we have a separate staging websites for testing, as well as an entirely different site using the same plugin – all of these instances have no issue, however we have consistent issues with 2 production websites tested where we receive the “ERROR: Invalid verification code.” message when using the authentiactor app.
All of these websites are running the same version of WordPress, and run in a containerised environments within the same Kubernetes cluster so the server configuration is pretty much identical across instances, barring a few differences in things like caching, PHP version and plugins installed.
For reference, I have listed below the various instances we have tested and whether or not access via authenticator is working (after initial setup):
- Website 1 (Staging Environment, PHP 8.1, no caching): Works
- Website 1 (Production Environment, PHP 8.1, caching): Works
- Website 2 (Staging Environment, PHP 7.4, no caching): Works
- Website 2 (Production Environment, PHP 7.4, caching): Does not work
- Website 2 (Production Environment, PHP 7.4, no caching): Does not work
- Website 3 (Staging Environment, PHP 7.4, no caching): Works
- Website 3 (Production Environment, PHP 7.4, caching): Does not work
- Website 3 (Production Environment, PHP 7.4, no caching): Does not work
The thing that stands out as odd to us is how everything works via authenticator app on the staging environments for Websites 1 and 2, but not the production environments, where the only major differences are the presence of caching as well as a different database server. The exception is for Website 1 – which works fine in both environments, however 2FA was initially configured on this website using an older version of the plugin that has since been upgraded.
Additionally, on the production sites where the authenticator app does not work we have tested e-mail based 2FA and we can confirm this does work.
We do have a staging environment, with the same setup just minus the caching and it works properly there. We’ve tried disabling all caching along with any other plugins that could affect login (reCAPTCHA, WPS Hide Login, Disable REST API), and we’re still getting the same error. These plugins are all enabled on staging and 2FA works properly there. Something to note is the backup codes are working correctly, it’s just the 2FA code when trying to login that throws the error.
Sorry, I know that’s not a lot to go on but we’re at a bit of a loss as to what’s causing this issue!
- This reply was modified 1 year, 6 months ago by devteamzeal.
- This reply was modified 1 year, 6 months ago by devteamzeal.
- WordPress version 6.6.2, PHP 7.4, WP 2FA version 2.8.0
- We’re using the Google Authenticator app
We are also using both Redis Cache and W3 Total Cache, are you aware of any issues using either of these with WP 2FA?
- This reply was modified 1 year, 6 months ago by devteamzeal.
The issue is affecting all users, including newly created users. If we go into the user and reconfigure 2FA from the profile page the issue still persists. It’s happening across multiple devices. The initial setup with the first validation code in the wizard works, it only throws the error when trying to login after 2FA has been configured.
Thank you for your response. We can confirm the server, website, and devices timezones are all in sync. It it is affecting all users.
Forum: Plugins
In reply to: [Conditional Content by Crowd Favorite] Critical issues in Site Health checkHi there,
I’ve just tried updating the plugin to version 2.1.0 and that did not resolve the critical issues. It seems to be linked to the session_start() on line 13 of conditional-content-cf-lite\public\class-cf-cc-public.php. There is no session_write_close() within the file, hence the critical issue saying “A PHP session was created by a session_start() function call. This interferes with REST API and loopback requests. The session should be closed by session_write_close() before making any HTTP requests.” When I add session_write_close() to the end the critical issues no longer appear in the site health check.
I’d like to implement this fix but don’t want to edit the plugin directly. What would be the best way to implement this fix?
Many thanks