lockout notification despite deactive setting

Hi Georg,

Apart from unticking the Site Lockouts notification Enabled checkbox, make sure to click on the blue Save All button as well.

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

Ok, I see. If your site is under heavy brute force attacks, sometimes the large amount of lockout emails are causing delays in delivery. Give it a moment and you should see it stop.

It’s also advisable to review the data in the plugin Logs page. It will help you identify which brute force method is being used. Once the method is identified you can take the appropriate steps to stop that type of brute force attack.

Large amounts of lockout emails can be a nuisance, but it does mean the plugin is protecting your site. Ideally you want the lockout notifications enabled at all time. Receiving a large amount of lockout emails is a sign your site is probably not fully hardened yet.

• This reply was modified 1 year, 8 months ago by nlpro.
• This reply was modified 1 year, 8 months ago by nlpro.
• This reply was modified 1 year, 8 months ago by nlpro.

Hi Mr. pkirk,

The procedure below describes how you can check the current value for the “enabled” setting of the lockout notification.

First enable the extra Debug page by adding the line below to the WordPress wp-config.php file:

define('ITSEC_DEBUG', true);

Then simply navigate to the Security > Debug menu option.
In the Settings section select “notification-center” from the drop-down list and then click on the Load button.

Under “notifications” look for “lockout” and then verify the boolean value for “enabled”.

If the value is false no new lockout notifications will be send.

Why?

Because the callback that sends the lockout notification (email) FIRST checks the current value of the “enabled” setting and only when that value equals to true it will continue sending the email. Otherwise (false) the callback execution ends (return;).

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

@pkirk

Thank you for your feedback. Glad to hear the issue is now resolved.

@fuhrmann6020

My post to pkirk may help you (and others) as well. Please give it a try and let me know the result.

Hi pkirk,

I think it’s a react/iTSec or caching issue.

I noticed that if you simply change an option like this through the UI (not from the Debug page), whether you tick or untick the checkbox, without clicking on the Save All button, the UI holds on to the last state. Navigating away from the page and then returning to that same page (or simply refreshing the page) does not return the checkbox to the state of the actual stored value in the database. This is extremely confusing!

The only sign telling me that the UI is not in sync with the value as stored in the database is the Save All button showing as not greyed out.

Not sure whether this is a (react/iTSec) bug or how to deal with this.

@timothyblynjacobs
Why does react hold on to the last performed UI action instead of syncing the UI with the actual setting value(s) as stored in the database?

Hi @timothyblynjacobs,

As usual you are making total sense.

However this does mean, that it’s probably not a good idea to use the Debug page for making changes in database settings.

Or is there a way to manually sync/clear the UI local cache using the browser console (or any react tool)?

Anyway this is quite a change to what we were used to in the old days.
Good to hear you’ll explore additional ways to make this more clear.