Conflict between AIOWPS and HTTPS to HTTP rule

Or here’s a simpler version of the .htaccess rule, if it makes it any easier to eliminate the conflict:

RewriteEngine On
#If we have https
RewriteCond %{HTTP:X-Forwarded-SSL} =on
#And its not one of these slugs
RewriteCond %{REQUEST_URI} !/(wp-admin|wp-login|mysecretloginurl)(/.*)?
#send to http
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

Ok thanks for the info.
We will need to investigate this further.
Just out of curiosity, how does the Cookie Based Brute force prevention feature behave on your site?

I’ve never tried Cookie Based Brute force prevention on our site.

By the way, my hosting provider requires

RewriteCond %{HTTP:X-Forwarded-SSL} =on

but on most hosts it would be

RewriteCond %{HTTPS} =on

I’ve never tried Cookie Based Brute force prevention on our site

Can you try a quick test and let me know what behaviour you see?

OK, I did a quick test of Cookie Based Brute force prevention.

I observed the results in Safari, because Safari appears to show redirect activity more clearly than other browsers. (Even so, I had to make a screen movie and watch it in slow motion to catch all the changes!)

My .htaccess rule not active:

When entering https://mydomain.com/?secretloginword=1
it redirects to https://mydomain.com/wp-admin
then to https://mydomain.com/wp-admin/
then to https://mydomain.com/wp-admin/
and finally to https://mydomain.com/wp-login.php?redirect_to=https%3A%2F%2Fmydomain.com%2Fwp-admin%2F&reauth=1

With my .htaccess rule active:

it redirects to https://mydomain.com/?secretloginword=1
then to https://mydomain.com/wp-admin
then to https://mydomain.com/wp-admin
then to https://mydomain.com/wp-admin/
then to https://mydomain.com/wp-admin/
and finally to https://mydomain.com/wp-login.php?redirect_to=https%3A%2F%2Fmydomain.com%2Fwp-admin%2F&reauth=1

I don’t see any of that kind of redirecting happen if I use the hidden login URL (unless I type in https://mydomain.com/mysecretloginurl …in which case it is redirected to https://mydomain.com/mysecretloginurl).

I should mention that I edited the RewriteCond to include secretloginword

Hi peter-a,
ok thanks for the test and clarification.

So it appears that with the cookie based brute force feature you are able to successfully protect your login page and also be able to access it when you need to log in – even after the series of redirects you explained.

Is my assumption correct?

Yes.

Because of this conflict, I am unable to still use the rename-login feature, and I am now seeing more attempted attacks on my site. Any progress or suggestions?

Unfortunately I need to use some kind of force-http function for my site to function properly —?otherwise Google sends people to https, which breaks some site elements.

Hi,
I’m a little confused now – I thought you stated earlier that the Cookie Based Brute Force Prevention feature was working fine on your site. I then assumed that you would use that instead of the rename login page feature to protect your login page.

So is the cookie based feature not working either?

Considering conflicts with HTTPS, I have noticed that when I enable AI1WPS, it disables the WordPress HTTPS plugin. (https://www.ads-software.com/support/plugin/wordpress-https)

Is there some way to resolve the conflict? Would it impossible to include HTTPS rules in with your plugin so we don’t have to use external HTTPS rules?

WP 3.9.2
AI1WPS v. 3.7.6
WP HTTPS v. 3.3.6

Thanks

Hi thedirector27 please see below.

• your AI1WPS v. 3.7.6 should be updated to the latest version.
• The following plugin WP HTTPS v. 3.3.6 has not being updated for a long time and the websites says it is only compatible with WordPress 3.5.2. I don’t recommend using this plugin for security reasons.

Kind regards