403 Error with BPS Version .51.2

Nothing changed as far as htaccess rules or functionality goes in BPS .51.2. What did change is file structure and the order of code in the root .htaccess file. In other words, there were no changes made in BPS .51.2 that could cause this problem.

So what is probably happening is this: When you did the one-time manual steps in BPS .51.2 your custom code was recreated in your root htaccess file by doing those steps and either your custom code is not correct or it is missing some IP addresses or of course the most obvious thing: your ip address or addresses have changed or are different.

Check your IP based code in Custom Code and make sure it is correct and then do the Custom Code steps again.
1. Edit/correct your custom code.
2. Click the Save Root Custom Code button.
3. Go to the Security Modes page, click the Create secure.htaccess File AutoMagic button and activate Root folder BulletProof Mode.

Thanks for your reply.

All IPs are fixed and have definitely not changed.

This is my custom code (actual IPs obscured):

<FilesMatch “^(wp-login\.php)”>
SetEnvIf X-FORWARDED-FOR “^x\.x\.x\.x$” allowedip
SetEnvIf X-FORWARDED-FOR “^x\.x\.x\.x$” allowedip
SetEnvIf X-FORWARDED-FOR “^x\.x\.x\.x$” allowedip
SetEnvIf X-FORWARDED-FOR “^x\.x\.x\.x$” allowedip

order allow,deny
deny from all
allow from env=allowedip
</FilesMatch>

I have already re-created and re-activated the secure .htaccess file without success.

I have just cleared the browser (Firefox) cache and cookies (and locked myself out again as a result).

Something else is at play here.

I believe the problem is that you have the SetEnvIf conditions inside of the FilesMatch condition. Also reverse the “Order” directive from Allow,Deny to Deny,Allow since you are only matching the IP conditions and not other things like Server IP, Host, domains, etc.

SetEnvIf X-FORWARDED-FOR "^x\.x\.x\.x$" allowedip
SetEnvIf X-FORWARDED-FOR "^x\.x\.x\.x$" allowedip
SetEnvIf X-FORWARDED-FOR "^x\.x\.x\.x$" allowedip
SetEnvIf X-FORWARDED-FOR "^x\.x\.x\.x$" allowedip

<FilesMatch "^(wp-login\.php)">
Order Deny,Allow
Allow from env=allowedip
Deny from all
</FilesMatch>

Thanks, those changes did the trick.

Any idea why the original code I used, which was described by you in this post, stopped working when BPS .51.2 was installed? For example, in your original post, you said the correct order was allow,deny and also that “You can use SetEnvIf X-FORWARDED-FOR inside or outside of the FilesMatch section of code”.

Looks like most of the example code in that post is good, but yeah there is one bad example in that thread/post. It happens. ??

And nope this is not correct: “You can use SetEnvIf X-FORWARDED-FOR inside or outside of the FilesMatch section of code.” I have only used SetEnvIf outside of the FilesMatch condition because it would not work inside the FilesMatch condition for that particular check obviously.

My point was that with the SetEnvIf X-FORWARDED-FOR inside the FilesMatch section of code, the code worked perfectly for 12 months – it worked, in fact, until I installed BPS .51.2 ??

The only logical thing I can think of is that the code was saved to Custom Code, but it did not actually exist in your root htaccess file.

Nice try, but not correct ?? In addition, the custom code as I originally posted it in this thread exists exactly as written in the root .htaccess file on 3 other of my websites which I did not update BPS on once I discovered the issue with 51.2 – those sites are still all using 51.1 at the moment, and I have no problem logging in and out of them.

I suspect there’s some code interaction going on which only became apparent with the changes introduced in 51.2. In any event, I’ve got the code working on 51.2 now thanks to your help ??

I’ve now updated all my sites to .51.3, so I’m adding to this thread with a bit more info …

After updating the first site (which I had the difficulty with discussed in this thread) I did some experiments. First, I reverted the custom code to the version that was working with .51.1 and logged out. There was a 403 error which locked me out – I removed the .htaccess file and logged back in. Next I tried just changing the “Order” directive from Allow,Deny to Deny,Allow while leaving the SetEnvIf X-FORWARDED-FOR inside the FilesMatch section of code. I logged out again – no 403 error, no lock out, and I was able to log back in. I decided to quit while I was ahead and left the custom code like that.

I then updated all the other sites, one by one, from .51.1 to .51.3, and tested each site in turn. What I found was that without changing the existing custom code in any of them I had no problem logging in and out – no 403 errors appeared. The only difference between the custom code in all these sites and the first site is the order directive: these sites have Allow,Deny whereas, as noted above, the first site now has Deny,Allow.

So, from my experiments it appears:

1) there is some interaction going on in the first site, be it a plugin or custom code or something else – the problem is fixed by making one change: using Deny,Allow instead of Allow,Deny

2) having the SetEnvIf X-FORWARDED-FOR inside the FilesMatch section of code works fine

I thought it was worth documenting this because other people using CloudFlare (or another CDN) in conjunction with BPS will need to use SetEnvIf X-FORWARDED-FOR in their custom code – for my sites it doesn’t matter whether this is inside or outside the FilesMatch section of code.

Ok great! Thanks for the helpful info. ??