Title: Conflict between AIOWPS and HTTPS to HTTP rule
Last modified: August 22, 2016

---

# Conflict between AIOWPS and HTTPS to HTTP rule

 *  [peter-a](https://wordpress.org/support/users/peter-a/)
 * (@peter-a)
 * [11 years, 9 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/)
 * 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/](https://wordpress.org/plugins/all-in-one-wp-security-and-firewall/)

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

 *  Thread Starter [peter-a](https://wordpress.org/support/users/peter-a/)
 * (@peter-a)
 * [11 years, 9 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185836)
 * 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](https://wordpress.org/support/users/wpsolutions/)
 * (@wpsolutions)
 * [11 years, 9 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185873)
 * 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](https://wordpress.org/support/users/peter-a/)
 * (@peter-a)
 * [11 years, 9 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185874)
 * I’ve never tried Cookie Based Brute force prevention on our site.
 *  Thread Starter [peter-a](https://wordpress.org/support/users/peter-a/)
 * (@peter-a)
 * [11 years, 9 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185875)
 * 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](https://wordpress.org/support/users/wpsolutions/)
 * (@wpsolutions)
 * [11 years, 9 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185876)
 * > 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](https://wordpress.org/support/users/peter-a/)
 * (@peter-a)
 * [11 years, 9 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185894)
 * 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](https://mydomain.com/?secretloginword=1)
   it redirects to [http://mydomain.com/wp-admin](http://mydomain.com/wp-admin) 
   then to [http://mydomain.com/wp-admin/](http://mydomain.com/wp-admin/) then to
   [https://mydomain.com/wp-admin/](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](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](http://mydomain.com/?secretloginword=1)
   
   then to [http://mydomain.com/wp-admin](http://mydomain.com/wp-admin) then to 
   [https://mydomain.com/wp-admin](https://mydomain.com/wp-admin) then to [http://mydomain.com/wp-admin/](http://mydomain.com/wp-admin/)
   then to [https://mydomain.com/wp-admin/](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](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](http://mydomain.com/mysecretloginurl)…
   in which case it is redirected to [https://mydomain.com/mysecretloginurl](https://mydomain.com/mysecretloginurl)).
 *  Thread Starter [peter-a](https://wordpress.org/support/users/peter-a/)
 * (@peter-a)
 * [11 years, 9 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185901)
 * I should mention that I edited the RewriteCond to include `secretloginword`
 *  Plugin Contributor [wpsolutions](https://wordpress.org/support/users/wpsolutions/)
 * (@wpsolutions)
 * [11 years, 9 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185925)
 * 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](https://wordpress.org/support/users/peter-a/)
 * (@peter-a)
 * [11 years, 9 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185926)
 * Yes.
 *  Thread Starter [peter-a](https://wordpress.org/support/users/peter-a/)
 * (@peter-a)
 * [11 years, 8 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185985)
 * 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](https://wordpress.org/support/users/wpsolutions/)
 * (@wpsolutions)
 * [11 years, 8 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185986)
 * 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](https://wordpress.org/support/users/thedirector227/)
 * (@thedirector227)
 * [11 years, 8 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185989)
 * 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](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](https://wordpress.org/support/users/mbrsolution/)
 * (@mbrsolution)
 * [11 years, 8 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185993)
 * 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

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

The topic ‘Conflict between AIOWPS and HTTPS to HTTP rule’ is closed to new replies.

 * ![](https://ps.w.org/all-in-one-wp-security-and-firewall/assets/icon-256x256.
   png?rev=2798307)
 * [All-In-One Security (AIOS) – Security and Firewall](https://wordpress.org/plugins/all-in-one-wp-security-and-firewall/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/all-in-one-wp-security-and-firewall/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/all-in-one-wp-security-and-firewall/)
 * [Active Topics](https://wordpress.org/support/plugin/all-in-one-wp-security-and-firewall/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/all-in-one-wp-security-and-firewall/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/all-in-one-wp-security-and-firewall/reviews/)

## Tags

 * [HTTPS](https://wordpress.org/support/topic-tag/https/)
 * [rename login url](https://wordpress.org/support/topic-tag/rename-login-url/)

 * 13 replies
 * 4 participants
 * Last reply from: [mbrsolution](https://wordpress.org/support/users/mbrsolution/)
 * Last activity: [11 years, 8 months ago](https://wordpress.org/support/topic/conflict-between-aiowps-and-https-to-http-rule/#post-5185993)
 * Status: not resolved