Conflict between AIOWPS and HTTPS to HTTP rule

peter-a
(@peter-a)

11 years, 9 months ago
I’m using v3.7.9 of the plugin, and I am using the Rename Login URL function. I have created an .htaccess rule to redirect all https links to http except for anything containing wp-admin, wp-login, or mysecretloginurl:
```
# BEGIN Redirect most HTTPS to HTTP
RewriteEngine On

RewriteCond %{HTTP:X-Forwarded-SSL} !on
RewriteCond %{REQUEST_URI} ^\/(wp-admin|wp-login|mysecretloginurl)
RewriteRule (.*) https://%{HTTP_HOST}/$1 [L,R=301]

RewriteCond %{HTTP:X-Forwarded-SSL} =on
RewriteCond %{REQUEST_URI} !^\/(wp-admin|wp-login|mysecretloginurl)
RewriteRule (.*) http://%{HTTP_HOST}/$1 [L,R=301]
# END Redirect most HTTPS to HTTP
```
However the problem is that with this code active, mydomain.com/mysecretloginurl redirects to the mydomain.com home page.

This happens whether I place my code before or after the AIOWPS rules in .htaccess/

https://wordpress.org/plugins/all-in-one-wp-security-and-firewall/

Viewing 13 replies - 1 through 13 (of 13 total)

Thread Starter peter-a
(@peter-a)

11 years, 9 months ago
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 .* http://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
```
Plugin Contributor wpsolutions
(@wpsolutions)

11 years, 9 months ago

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?

Thread Starter peter-a
(@peter-a)

11 years, 9 months ago

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

Thread Starter peter-a
(@peter-a)

11 years, 9 months ago

By the way, my hosting provider requires

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

but on most hosts it would be

RewriteCond %{HTTPS} =on

Plugin Contributor wpsolutions
(@wpsolutions)

11 years, 9 months ago

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?

Thread Starter peter-a
(@peter-a)

11 years, 9 months ago

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 http://mydomain.com/wp-admin
then to http://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 http://mydomain.com/?secretloginword=1
then to http://mydomain.com/wp-admin
then to https://mydomain.com/wp-admin
then to http://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 http://mydomain.com/mysecretloginurl …in which case it is redirected to https://mydomain.com/mysecretloginurl).

Thread Starter peter-a
(@peter-a)

11 years, 9 months ago

I should mention that I edited the RewriteCond to include secretloginword

Plugin Contributor wpsolutions
(@wpsolutions)

11 years, 9 months ago

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?

Thread Starter peter-a
(@peter-a)

11 years, 9 months ago

Yes.

Thread Starter peter-a
(@peter-a)

11 years, 8 months ago

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.

Plugin Contributor wpsolutions
(@wpsolutions)

11 years, 8 months ago

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?

thedirector27
(@thedirector227)

11 years, 8 months ago

Considering conflicts with HTTPS, I have noticed that when I enable AI1WPS, it disables the WordPress HTTPS plugin. (http://wordpress.org/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
Plugin Contributor mbrsolution
(@mbrsolution)

11 years, 8 months ago
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