Plugin Author
Eli
(@scheeeli)
There were no changes to the Brute-Force Protection in that last few updates. The protection itself is included in your wp-config.php file and that does not change when you upgrade the plugin. The include file gotmls/safe-load/wp-login.php has not changed since version 4.14.53 (over 5 months ago).
There are lots of other changes that could affect this protection though. For starters, this protection method is session based so if there is some new change on your site or on the server that would affect the way sessions are stored that could trigger these false alarms.
There could also be another plugin that change or got added recently that might be interfering with the session.
Please let me know if you need more help troubleshooting this issue. I’m happy to help you get the bottom of this. You can also disable this protection if you just need to get people logging in again.
We disabled your plugin immediately upon learning the problem Wednesday morning and some users still encounter “3057863 You have been redirected here from ehrmanblog.org which is protected against brute-force attacks by GOTMLS.NET” We have been using the DEFAULT .HTACCESS file all along, where the brute force addition was a problem when initiated with the Magic Members plugin. The dedicated server was checked for any issues by the techs at WiredTree and none seem to exist. At a loss here.
After a good deal of research, we found that the /tmp directory on the server’s root had nearly exceeded its allocated space. Over time files get orphaned in this directory and it fills. As a result, any database calls or sessions could not be completed successfully. The issue was the tmpwatch utility package was not installed. Basically what this does is remove files from /tmp that are older than 10 days (as configured). We have reactivated Gotmls 4.15.20 without further complications after almost a 24 hour period.
It would be beneficial that an GOTMLS error message will show the actual cause of a failed session due to no space in /tmp on the server, verses the redirect message that did not announce the problem. This can be easily identified by script from the error_log file found at the WordPress root. The error message read:
[13-May-2015 15:29:36 America/Chicago] PHP Warning: Unknown: write failed: No space left on device (28) in Unknown on line 0
[13-May-2015 15:29:36 America/Chicago] PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0
The PHP Warnings were repeated many times in the error log, consistent with failed login attempts. Some of the error message is a constant, sufficient to identify via a script to echo the error, despite the variable details.
Thanks.
Plugin Author
Eli
(@scheeeli)
Thanks for the extra details. I glad you figured it out. Looking at the error log is always a good place to start 😉
I will look into capturing the PHP errors so that they can be passed along to the end user.
