You don’t have permission to access /wp-login.php on this server

[AITpro Admin]

@ Scott – “…and the code kept reappearing…”.  I assume AutoRestore|Quarantine was autorestoring the root htaccess file.  See this ARQ Guide section on AutoRestore|Quarantine Manual File Editing/Uploading Procedural Steps:  http://forum.ait-pro.com/forums/topic/autorestore-quarantine-guide-read-me-first/#procedural-steps  In your particular case/scenario you were forced to rename the /bulletproof-security/ plugin folder instead to fix this problem because it was a login problem that would not allow you to do the standard ARQ procedural steps.  Renaming the /bulletproof-security/ plugin folder is the manual alternative to turning AutoRestore|Quarantine Off when you can login to your site.

Standard BPS Custom Code and saved custom/personal htaccess code should not be deleted automatically from Custom Code because someone would loose all their custom htaccess code and then have to re-add it all back again.  The BRUTE FORCE LOGIN PAGE PROTECTION htaccess code is Bonus Custom Code and it is not standard BPS htaccess code that is provided in any BPS Standard htaccess files for exactly this reason:  The problem that occurred on your site/host/server (that Bonus Custom code has a 95%|5% success|failure ratio – works on 95% of sites/hosts/servers and not on 5% of sites/hosts/servers).  The BRUTE FORCE LOGIN PAGE PROTECTION htaccess code works exactly the same in BPS free and Pro.  Either it works on your site/host/server or it does not.  There is no difference regarding having the BPS free or Pro version installed.  So what most likely happened is this scenario if this problem did not occur until you installed BPS Pro:  You saved the BRUTE FORCE LOGIN PAGE PROTECTION htaccess code to BPS Custom Code, but it was never actually created in your Live root htaccess file.  It was only saved to Custom Code.  Then when you ran the BPS Pro Setup Wizard the BRUTE FORCE LOGIN PAGE PROTECTION htaccess code was created in your root htaccess file.

Or another likely possible cause for why the problem starting happening all of a sudden.  Something else changed on your server like a Proxy was added that uses the older HTTP/1.0 Server Protocol or something else external along those lines (Browser Proxy software that uses the older HTTP/1.0 Server Protocol).

[Scott]

You saved the BRUTE FORCE LOGIN PAGE PROTECTION htaccess code to BPS Custom Code, but it was never actually created in your Live root htaccess file. It was only saved to Custom Code. Then when you ran the BPS Pro Setup Wizard the BRUTE FORCE LOGIN PAGE PROTECTION htaccess code was created in your root htaccess file.

Okay, assuming that’s what happened, what do I need to do to restore Brute Force Login Page Protection [BFLPP]? My host (Media Temple) tells me that nothing has changed, so the older http protocol explanation doesn’t make sense as the cause, and again, the BFLPP custom code was working fine in the free version, and for a week in the pro version.

If I’m following what you’re suggesting–that some sort of conflict was created when I ran the pro setup wizard–then I should be able to add the code back in to custom code because running the pro wizard is no longer a consideration. Is my understanding accurate? I’d give it a try without asking you, but I dread having to fix everything again in case my understanding is wrong. And yes, I understand that you can’t guarantee results, I’m asking the question on the assumption that your speculation about the setup wizard/existing custom code is accurate. Thanks.

[AITpro Admin]

@ Scott –  Unfortunately, you cannot really rely on what your host support tells you if you are asking about server changes.  The reason for that is a lot of times the frontline support techs are not aware of any server changes made by their server administrators because they are not informed about any changes at the server level.  So the frontline support tech is not a fault and is just not informed.  I know this well from experience because with my own host support techs, which are top notch, the only questions I ask of them are high level questions regarding host servers that would normally require a server administrator to answer my questions.  Usually my host support techs are not able to answer my questions and I end up having to create frontend code to test what is happening or changed on my host servers.  That is unfortunately pretty common for me.

So one thing is for sure.  Something has changed.  Either on the server or with however you are accessing your website.  ie a new Proxy has been added on your host server that is using the outdated HTTP/1.0 Server Protocol or you are using a Browser/VPN/Proxy that is using the outdated HTTP/1.0 Server Protocol. I cannot think of any other logical explanations.

Nope this has nothing to do with BPS or any BPS features at all.  The issue is simply that the BRUTE FORCE LOGIN PAGE PROTECTION htaccess code either does not work on your host server or however you are accessing your website is being blocked due to whatever you are using:  Proxy/VPN/etc in your Browser or your connection method to your site.

So in summary you can do these testing things below to isolate whether the BRUTE FORCE LOGIN PAGE PROTECTION htaccess code does not work on your particular host server or however you are accessing your website is being blocked by the htaccess code.

Note:  The BRUTE FORCE LOGIN PAGE PROTECTION htaccess code is Bonus Custom Code that blocks nuisance bots and is not really critical or essential to your website’s overall security since all of the other BPS Pro security features completely protect websites.

1. Turn AutoRestore Off.
2. Manually edit your root htaccess file using FTP and add the BRUTE FORCE LOGIN PAGE PROTECTION htaccess code in your root htaccess file.
3. Use a different Browser or connection method that does not involve a Proxy/VPN or anything else that is non-standard.  You want to do a basic Browser check with no add-ons/extensions loaded to eliminate your Browser or connection method. And to confirm that the htaccess code does not work on your particular host server.
4. At this point you will have isolated whether or not the problem is your host server or your Browser/connection method.
5. If your host server does not allow this Bonus Custom code then you cannot use it on your host server and will have to delete it.
6. If the problem is with your Browser or connection method then the choice is up to you whether or not you want to deal with the extra hassle of using different connection methods just to use this Bonus Custom Code.

[Author]

Posts