pronl

@stuartb3502

People tend to go in panick mode when the plugin locks them out.
But there is no need to.

These lockouts are temporary, which means they are released automatically after (by default) 15 minutes.
So normally there is absolutely no need to delete anything in the database.

That said, the lockout code includes some bugs which makes it unpredictable. Basically it is not functioning properly.

And in your particular case you do need to delete any records in the lockouts as well as the temp table. Its totally unharmfull.

Do note that the plugin adds 2 purge cron jobs when installed.
This ensures the 3 plugin tables are purged on a regular basis.

The lockouts and temp table are purged by the itsec_purge_lockouts cron job. It deletes any records older than 7 days.

The logs table is purged by the itsec_purge_logs cron job. By default records older than 2 weeks are deleted. This is actually configurable in the General Settings module.

Both cron jobs run daily.

@morjachok

Tested (on Windows 7), but that will only work for files. It does not work for directories/folders.

I did manage to set the permissions on a Windows directory to 555 but it seems to be inconsistant on different directories. Not sure what’s happening …

Anyway the code checks for 755 and I still don’t think you can get that on a Windows platform. Perhaps when using acl’s (Access Control Lists)…
Also note that 755 is rwxr-xr-x
Windows Read only file property = r–r–r– = 444

Since the plugin checks directories for 755, 444 does not equal 755, so not sure how you solved this … Seems to me this simply cannot be resolved on a Windows platform.

Also only if the plugin would check directory permissions <= 755 (LESS or equal) it would turn the status column to green when 555 is detected …

@mattkslx

Was that backup email the result of a manual backup (= clicking on the ‘Create a Database Backup’ button) ?

According to the execute_backup() method in the wp-content/plugins/better-wp-security/core/modules/backup/class-itsec-backup.php file:

...
if ( 2 !== $this->settings['method'] || true === $one_time ) {
	$mail_success = $this->send_mail( $file );
}
...

So looks like manual database backups send emails irregardless the Backup Method chosen …

@yaribernardus

Looks like the plugin install got corrupted.

Logout, delete the wp-content/plugins/better-wp-security folder and manually install the plugin using ftp or any Hosting Control Panel interface. Then login and activate the plugin (if necessary).

@yorman

Thank you for your excellent support.
No one ever says so on these forums but I think you are doing a great job !

… was caused by an override of the global $locale variable, which works well for the core pages, but seems to affect some 3rd-party plugins.

So your plugin is no longer overriding the global $locale variable ?

It’s not that some 3rd-party plugins are doing something wrong with language ?

@aboutnick & @menken

This is known bug that has already been fixed in the Pro 4.0.0 release.

Bug Fix: Fixed an infinite loop that could occur when expiring a cookie and Hide Backend is enabled.

It is almost 4 months ago the free plugin was last updated so I expect an update any moment.

If you can’t wait for the next update to the free plugin to be released the issue can also be fixed manually. It only requires a simple change in one of the Hide Backend methods which is located inside the better-wp-security/core/modules/hide-backend/class-itsec-hide-backend.php file.

@morjachok

This plugin was not written to run on a Windows platform …
It appears to function … but with numerous Windows platform specific bugs.
You just stumbled on one of those bugs.

You simply cannot get 755 permissions on Windows folders.
Save yourself a lot of troubles and stop running this on a Windows server platform.

I just updated the plugin from 1.8.3 to 1.8.6 and I can confirm there seems to be an issue with the WordPress Site Language setting.

I had it set to a non English (United States) language but after updating your plugin it seems to be set and stuck to English (United States). Trying to change the Site Language setting fails. Strange thing is that the Dashboard language is actually still displayed in the non English (United States) language …

Deactivating the plugin immediately restores the correct display and functioning of the Site Language setting in the General Settings page …

Really think this needs your immediate attention ??

Oh by the way I’m on WordPress 4.7.5, PHP 7.0.3, Apache 2.4.18, MySQL 5.7.13

error_log shows some of these (probably unrelated and PHP 7 specific):

Deprecated: Non-static method SucuriScanSiteCheck::ajaxMalwareScan() should not be called statically in C:\\trumpisanidiot\\wp-content\\plugins\\sucuri-scanner\\src\\pagehandler.php on line 187, referer: https://www.trumpisanidiot.com/wp-admin/admin.php?page=sucuriscan

Every class method is defined as static in the SucuriScanSiteCheck class except the last method: ajaxMalwareScan() …

@yorman
Looks like our posts crossed one another. Just noticed your post (4 minutes earlier than mine). Anyway happy to hear the Site Language issue is being dealt with.
So now only expecting a short reacting on the Non-static method issue … ??

• This reply was modified 7 years, 9 months ago by pronl.

Turns out the order of the code is actually correct.

The wp_authenticate_user filter is used for testing extra password criteria.
The hooked callback is supposed to validate the data passed in the $password argument. Like: Is the provided password lenght > 8 characters ? If this extra password criteria is NOT met, there is no point in doing the regular password validation…
So it’s actually correct that the extra password criteria are executed first.

However I’m not adding an extra password criteria that can be tested using the $password argument. Instead I’m using the callback to validate a password expiration datestamp stored in the wp_usermeta table.
For this specific purpose it would better fit if a (possibly new) filter is applied AFTER the regular password validation.

Anyway I finally managed to tweak my callback in such a way that it behaves as desired.

So I guess I answered my own question ??

@hitec4ever

Ok, that’s something I can work with.

A quick Google search on the Apache “AH01067: Failed to read FastCGI header” msg seems to point in the direction of the PHP OPcache module.

If PHP OPcache is enabled on the problematic env(s) its worth to try and disable it.
Not a solution but it will help determin whether this is also a PHP OPcache related issue.

If not we can rule OPcache out ??

@marekrz

Ok, so the @hitec4ever workaround helped you get back into the WordPress Dashboard.
BUT its not a solution for the root cause.

We don’t even know what the root cause is … Obviously its related to the Hide Backend feature. But that’s all we know. We don’t know what web server (version) and PHP version is being used. And we don’t know what plugin entries are added in the .htaccess (Apache) or nginx.conf (Nginx) file.
Last but not least we don’t know what extra info is available in the web server error_log.

So if you want to continue using the Hide Backend feature without hitting the 500 Internal Error msg you’ll need to investigate this a little bit further and/or provide ALL info that will enable people (like me) to identify the root cause.

Correct me if I’m wrong but this seems to be specific for certain 4.8 sites.
So it doesn’t seem to be generic even though several people have confirmed to hit a similar/identical issue.

@fiskhandlarn

Your issue is definately a bug but perhaps its worth mentioning the notice will only occur when accessing the frontend while logged in …

If not logged in, the notice will not occur.

In regards to the temporary fix, do note if you’re running PHP 5.2 or less then you can’t use anonymous functions…

@chilwell

Is there any chance of identifying which type of iTSec plugin email this is related to ?

Lockout email, Digest email, Backup Delivery email, File Change Detection email, Hide Backend confirmation email ?
Perhaps any emails send from the iTSec plugin ?

Or perhaps even worse, any emails send from that WordPress site …

@dsl225

Change the default value (3) to 1 for the Blacklist Threshold setting in the Global Settings module.

Do note this affects ALL lockouts which means the occurrance of banned IPs may significantly increase.

@kate515

… and this is happening while using WordPress 4.8 ?

The reason why I ask is because WordPress 4.8 includes an updated zxcvbn library for the strong password meter (1.0 to version 4.4.1).