Support

March 2, 2016 at 1:26 pm

Josh,
Ok, I hadn’t updated for a while but the last working version was 4.8.33.p. I havn’t tried reverting as I wasn’t sure if there were any chage to the database that might conflict by doing so.

What happens is when logged in the security pluggins trigger the lockouts from the ip you are logged in from.

Additional notes the user names from the htpassword protection on wp-login.php are being logged along with the ip og the logged in user.

I have tried a different computer and the same thing occurs.

Regards

March 2, 2016 at 1:29 pm

I did try disabling EE and the lockouts stopped.

March 2, 2016 at 2:02 pm

Do you have ssl and htpassword on wp-login?

Literally, clicked update from 4.8.33 to latest version then starte getting the emails from the lockout.

I will try reverting too.

Cheers for looking at this.

March 2, 2016 at 2:14 pm

Another thing I noticed… The EE promotions plugin diabled self. I noticed it earlier but didn’t think much and activated it – and now later I find it off again. Any ideas??

March 2, 2016 at 2:33 pm

I reverted to 4.8.33 and all seems ok, for now.

I noticed the promotion plugins being off after updating and off again later.. This is strange.

March 3, 2016 at 10:21 am

Apart from EE –
Adminimize
All in one SEO
Contact form 7
Loginizer – (I tried ‘Limit login attempts’ and got the same issue)
Simple custom post order
Toolset Type

The theme is really light too not many functions.

I was testing last week:

/* Auto logout
function kc_cookie_expiration( $expiration, $user_id, $remember ) {
    return $remember ? $expiration : 480;
}
add_filter( 'auth_cookie_expiration', 'kc_cookie_expiration', 99, 3 );*/
// Event Espresso

This was commented out and I had the same effect on a fresh machine?

Could it be SSL related – perhaps the htpassword conflicting between http and https. My admin is forced to SSL but if the htpassword box was accessed via http would that cause an issue?

The weird thing was that the user name from the htpassword was being passed to the wp-login.

I checked the logs and could see anything out of the ordinary.

March 4, 2016 at 3:40 pm

Ok Josh – I have done some testing with this.

There seems to be a conflict with the new version of EE if a htpassword cookie/session is active/stored in the browser. The presence of the htpassword session sends the brute force plugins crazy – thinking it is under attack on ever refresh by the logged in user.

It only occurs after updating from 4.8.33.

Htpassword on wp-login.php and login limiting plugins are pretty standard in protecting a WordPress site. Could you please look into this so we can update EE.

Many thanks.

March 7, 2016 at 7:21 am

Josh,
I think I may wait for the update rather than mess with the cookies.
Please let me know when you think it may be sorted.
Thanks for looking at this again.

March 14, 2016 at 4:51 pm

Hi, is there an ETA for this bug fix? Thanks.

March 15, 2016 at 8:01 am

Josh,
Great news…
Good to know but I will wait for the update – the admins can so it then.
Many thanks.

March 19, 2016 at 7:20 pm

Josh,
The fix didn’t solve the issue – it still keeps doing it (had to revert again). Can you please look at this again so I can use the update?

Thanks

March 22, 2016 at 8:13 am

The brute force prevention I am using.
https://wordpress.org/plugins/loginizer/

The trouble is the site is live and I don’t want to disrupt it.

March 24, 2016 at 4:17 pm

Josh,
Will this be updatable?

@Daniel – do you have this setup on a testing server Josh could look at?

I’m sure others must be having this issue please let us know so we can get a fix – many thanks to all.

March 25, 2016 at 11:52 am

@Daniel any chance you could add htpassword to your wp-login.php in .htaccess?

<FilesMatch "wp-login.php">
ErrorDocument 401 default
AuthName "Member Only"
AuthType Basic
AuthUserFile /add-the-path-to-your-password-here/.htpasswd
require valid-user
</FilesMatch>

It would be good for Josh to see that.

You can use http://www.htaccesstools.com/htpasswd-generator/ to help create the .htpasswd file credentials then update the server path to them in the code above.

March 29, 2016 at 1:49 pm

Correct me if I am wrong… When you authenticate with htpassword it creates a session cookie so you don’t have to login every time you hit that page – If the cookie/session expires or you close the browser you login to htpassword again.

The active htpassword session will be with the browser when you are navigating the admin (not loading it) and why shouldn’t it be? I wouldn’t want to keep authenticating every time I hit that page.

Wordpress recommends using htpassword to protect wp-login.php https://codex.wordpress.org/Brute_Force_Attacks as a way to bolster basic security along with brute force plugins (pretty standard stuff).

Once you have logged in and have the htpassword cookie saved in your browser the brute force plugins conflict with the latest EE changes. If you go to the brute force plugin settings page page and hit refresh in your browser the login attempts just keep increasing. Whatever EE is now doing to cookies means that htpassword cookies/sessions are now seen as a login attempt.

EE was fine before it changed to conflict with admin cookies/sessions why is this needed anyway?

I dont think this is an unreasonable request to get this fixed. EE is a nice bit of kit and you guys do a great job in responding to support requests – I just want this back working.

I appreciate your help.

March 29, 2016 at 2:10 pm

I did basic install on a friends server

Latest WordPress
EE
Loginizer
Htpassword on wp-login.php
Theme: Adamos

Nothing else.

All was fine with 4.8.33 – I deleted the plugin and downloaded the latest master from Git and uploaded. Loginizer started racking up brute forces on every refresh – I disabled EE and it stopped. The credentials used for the htpassword are seen as the login attempt in the email report.

All I can be sure of is that this isn’t happening with 4.8.33.

March 29, 2016 at 4:24 pm

Update – I have done some further testing and found that Loginizer has an update 1.1.0. I have used this with the Git release 4.8.39.rc.026 and it seemed ok the problem stopped. I need to see if this will work with other versions but I could be on to a fix. Thanks for your help, I will let you know how things go with it.