nlpro

Hi @emilieveber0612,

If you are unable to use 2FA to log in to your site, as a workaround add the following code (temporarily) to your wp-config.php file:

define('ITSEC_DISABLE_TWO_FACTOR', true);

This will disable 2FA for all users and allow you to login again.

That said, users should always configure Backup (Authentication) Codes as a second 2FA provider.

+++ To prevent any confusion, I’m not SolidWP +++

Ci-dessous la traduction de Google Translate en fran?ais:

Si vous ne parvenez pas à utiliser la 2FA pour vous connecter à votre site, ajoutez le code suivant (temporairement) à votre fichier wp-config.php comme solution de contournement:

define('ITSEC_DISABLE_TWO_FACTOR', true);

Cela désactivera la 2FA pour tous les utilisateurs et vous permettra de vous reconnecter.

Cela dit, les utilisateurs doivent toujours configurer les codes de sauvegarde (d’authentification) comme deuxième fournisseur 2FA.

+++ Pour éviter toute confusion, je ne suis pas SolidWP +++

• This reply was modified 5 months, 3 weeks ago by nlpro.

Hi?@agenziathinknow,

Try this. Navigate to Security > Settings > Advanced > System Tweaks

Disable (if not already) the Disable PHP in Plugins setting in the PHP Execution section. Scroll to the bottom of the page and save the settings.

+++ To prevent any confusion, I’m not SolidWP +++

Hi @swb1,

Not sure whether this info is usefull for what you want to do, but perhaps it adds a piece to your puzzle.

$user_id = get_current_user_id();
echo ITSEC_Lib_User_Activity::get_instance()->get_last_seen( $user_id );

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 5 months, 3 weeks ago by nlpro.

Hi @dave82-1,

Since you are hooking into the rest_dispatch_request filter with priority 99 your callback will be executed after the callback hooked (at priority 10) by the SolSec plugin. This means the $result argument will contain a WP_Error by the time it’s value is passed into your callback. So all you are doing is returning the WP_Error.

Instead hook 2 callbacks into the filter. One at a lower priority than 10 that only saves the value of $result into a global (and returns the $result value untouched), and one at a higher priority that returns the global value when the rest route contains /wp/v2/pages (Tested and it seems to work).

+++ To prevent any confusion, I’m not SolidWP +++

Hi @skunkworks,

Please let us know if you need any further assistance. If not, share how you managed to resolve the issue and then simply mark this topic as ‘Resolved’.

+++ To prevent any confusion, I’m not SolidWP +++

Hi @xaralouise,

Please let me know if you need any further assistance. If not, share how you managed to resolve the issue and then simply mark this topic as ‘Resolved’.

+++ To prevent any confusion, I’m not SolidWP +++

Hi @b1duck,

Make sure the ITSEC_DISABLE_TWO_FACTOR constant is not defined/enabled in the wp-config.php file. Ran into this myself recently ?? (Ran some tests but forgot to remove it).

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 5 months, 3 weeks ago by nlpro.

Hi @michaelrich,

According to the 6.3.0 Changelog:

Important: The way that Hide Backend functions changes in this release. Previously, if your Hide Backend Login Slug was wplogin, going to example.com/wplogin would result in the URL remaining example.com/wplogin. The new implementation of this feature results in a redirect to a URL that looks as follows: example.com/wp-login.php?itsec-hb-token=wplogin. While this may not be desireable for some users, this change was necessary to fix longstanding compatibility issues with other plugins. Once you access the login page using the Login Slug page, a cookie is set with an expiration time of one hour. As long as the cookie remains, you can access example.com/wp-login.php without having to access the Hide Backend Login Slug first. If you wish to confirm that Hide Backend is working properly on your site, opening up a private browsing window is a quick way to test without having to log out and clear cookies.

I hope the additional info helps you fix your issue ??

@shanedelierrr

Can the info above also be included into the?Solid Security Hide Backend?article as posted in the Solid Help Center ?

+++ To prevent any confusion, I’m not SolidWP +++

Hi @rockstar_tom,

Please activate the SolSec plugin and then try to add the?ITSEC_DISABLE_MODULES?constant to the wp-config.php file as described in the Solid Security FAQ post below:

How Do I Disable All Features If I Can’t Access My Site?

Note this is not a solution. Just a debugging step. Interested to hear the result.

@shanedelierrr

For a moment I was tempted to advise to add the ITSEC_DISABLE_MODULES constant to the wp-config.php file as described in the Solid Security FAQ below:

How Do I Disable All Features If I Can’t Access My Site?

(Even though I know a temporary lockout expires automatically after 15 minutes by default).

But I started to have doubts… so I checked the plugin lockout code. It seems adding the constant does not disable/ignore active (temporary) lockouts!

So I did a test and I can confirm that adding the ITSEC_DISABLE_MODULES constant to the wp-config.php file does not disable/ignore active (temporary) lockouts.

I know that the lockout code isn’t implemented as a module (it’s embedded in the plugin core code) so looking at this from that perspective it all makes sense. Still I wonder should the constant also disable/ignore active (temporary) lockouts ? I think it could be usefull. Or perhaps even better, introduce a new constant (ITSEC_DISABLE_LOCKOUTS) for disabling only the lockout code (similar to the constant ITSEC_DISABLE_TWO_FACTOR for disabling only the Two Factor module).

Hi @rockstar_tom,

What exact errors do you get?

I guess (temporarily) deactivating the SolSec plugin resolves the errors instantly?

Is this issue happening while using the latest version of the Solid Security plugin (9.3.3)?

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 7 months, 1 week ago by nlpro.

Hi @xaralouise,

If I’m not mistaken the email usually includes more info (like an Error Details section). Can you share all of the info from the email?

+++ To prevent any confusion, I’m not SolidWP +++

Hi @w-sky,

You may be interested in reading this topic.

+++ To prevent any confusion, I’m not SolidWP +++

Hi @skunkworks,

Just wanted to add 2 relevant pieces of info:

• Adding the ITSEC_DEBUG constant to the wp-config.php will also add a new Debug submenu option to the Solid Security plugin main Security menu. That is the Debug page @shanedelierrr is referring to.
• The Security Digest email is not send when there is nothing to report (even when the Debug page shows that it’s scheduled). Which totally makes sense. Nothing to report means, there have not been any lockouts nor any detected file changes since the last send Security Digest email.

Based on the fact that you changed the wp-config.php file, the File Change module should have picked up that change, consequently sending the Security Digest email. That is, if the File Change module is enabled!

I know the last Security Digest was in French language, but (if not deleted yet) please check it’s content (use Google translate if you have to). The email content will tell us what security event/feature triggered that Security Digest email to be send (lockout(s) and/or file change(s)).

• This reply was modified 8 months ago by nlpro.
• This reply was modified 8 months ago by nlpro.

Hi @rockso,

You may be interested in reading this topic.

+++ To prevent any confusion, I’m not SolidWP +++