Custom Code had old ip address but I was still able to log in

I have no idea about what occurred with the htaccess code you are talking about. BPS free does not do anything automated like that. BPS Pro does do real-time automation for certain things.

IP addresses are changed regularly and frequently by ISP’s so that is completely normal.

All BPS buttons have popup messages. Most of those popup messages are Reminders. ie did you do this or that. They are static reminder messages and are not anything dynamic that is checking anything – just simply reminders.

BPS automatically locks the root .htaccess file if you have turned AutoLock on. I’m not sure if BPS free retains whatever file permissions you had if you do not use AutoLock – BPS Pro does do that, but if you use AutoLock then your root .htaccess file will always be locked automatically.

The simple steps for BPS are these:
Turn AutoLock On (this is a one time setting)

1. Add your Custom Code and save it.
2. Go to the Security Modes page and click the AutoMagic buttons.
3. Activate BulletProof Mode.

I double checked and got confirmation that AutoLock is the correct method to automatically lock the root .htaccess file when doing anything with it in BPS.

Yes, thanks, I’m aware that ISPs will change ip addresses. And, yes, AutoLock is turned on.

But, as I said, I had updated my root htaccess custom code when my ip address changed about a month ago. That’s why I became concerned that the custom code – when checked yesterday – showed the previous ip address. We need to find out how this happened so it can be prevented from happening again, no?

For example, if I had forgotten to have BPS back-up the htaccess file(s) after making that code change a month ago, is it possible that the backup file was somehow made the active file? I ask this because if the ip address in the custom code is wrong, I am theoretically not supposed to be able to even gain access to the login page.

Yet, that was not the case yesterday, when the ip address was not correct and I was still able to log in.

Regarding the instructions, thank you for spelling out those three steps. But shouldn’t a backup be made after making changes to custom code? And, at what point after making a change to the custom code do the root folder htaccess file permissions revert to 644? Do they revert immediately after making the code change, or do they revert after clicking the AutoMagic buttons, or after activating Bulletproof Mode? I’m asking this so, rather than having to update the permissions to 404 several times, I make the update once. Please clarify the instructions to include this.

Thanks! I really appreciate your help.

BPS does not have the capability to change the IP address automatically.
BPS does not have the capability to restore a backup htaccess file automatically.

What I don’t know is exactly what really occurred. Maybe you thought something was something, but maybe it was not. I really don’t have any way of knowing that.

Here is what I know as fact:
htaccess code is literal so if IP address 99.88.77.66 is allowed and all other IP addresses are not allowed then only IP address 99.88.77.66 will be allowed. Since htaccess code is literal there is no inbetween – it can only be allow or do not allow.

So it is actually not possible that you were allowed to login with an IP address that is not allowed if the htaccess file and rule existed. There is no inbetween with htaccess rules. So unfortunately I cannot really tell you what might have happened and can only tell you what I know as fact about .htaccess files and code.

Yes, you can backup your htaccess files anytime you want to back them up. Or just recreate them again using AutoMagic. It is basically just a personal choice with that since either way produces the same result.

And, at what point after making a change to the custom code do the root folder htaccess file permissions revert to 644?

If you have AutoLock turned on then the answer is never. If your root .htaccess file is locked and you have AutoLock turned on then what happens is BPS unlocks the file to write to it and then locks it again after writing to it – that unlock/lock happens in a millisecond or 2.

Not really sure why you are experiencing problems on your particular site with this, but maybe it has to do with your Host or server or maybe something else you have installed on your website (another plugin, etc). I don’t see any other users in any other threads reporting this type of problem so maybe this is something new, but most likely isolated to just your website. Lucky you. ??

List all the plugins you have installed and I can tell you logically which plugin might have the capability to cause this type of problem.

Looking back through your thread history it looks like this problem has been occurring on your website for quite a while. At any point have you checked with your web host to see if they are automatically unlocking your root .htaccess file. I know that has happened in the past on 1 host, but I cannot remember the name of that host. I do remember that that particular host did not allow 404 file permissions for htaccess files and would automatically change 404 file permissions to 644 file permissions.

I have never checked with my host about whether or not they are unlocking my .htaccess file because I was never aware of a potential lock/unlock problem prior to today. But I can tell you that when I log in to my dashboard every morning and check Security Status, the permissions on the root folder .htaccess file are set to 404.

My root folder htaccess file is – and has been – locked, according to the little blue square that says ON immediately to the right of the Turn On AutoLock button. And I see the instruction that reads: “Use the Lock and Unlock buttons below to Lock or Unlock your root .htaccess file for editing.” However, thus far, anytime I’ve had to update my ip address, I’ve never first unlocked the file. Yet, upon saving the updated ip address, the change was accepted and there was never anything that told me otherwise.

A month ago, when my ISP changed my ip address without my knowing it, I tried to log in and the login page went into a redirect loop. That’s what made me realize my ip address must’ve changed. And, when I confirmed that it had, I was able to do what was necessary (temporarily disabled BPS) to log into my dashboard, update and save the custom code, after which I was able to log in conventionally again. So we know, at that time, nothing seemed amiss.

Just to confirm, the brute force login protection code I am using was copied from the first post on this page: https://forum.ait-pro.com/forums/topic/protect-login-page-from-brute-force-login-attacks/ The instructions on where to paste the code came from the same page: “If you have BPS or BPS Pro installed this custom .htaccess code goes in the CUSTOM CODE BOTTOM HOTLINKING/FORBID COMMENT SPAMMERS/BLOCK BOTS/BLOCK IP/REDIRECT CODE: Add miscellaneous code here text box.”

I just discovered that simply turning the Security Logging function on or off will cause the root folder .htaccess file permissions to revert to 0644.

My current plugins (which are all kept up-to-date; updated as soon as a new version is released):

– Akismet
– All In One Webmaster
– Bulletproof Security
– cforms
– Platinum SEO Pack
– Redirection
– SI Captcha Anti-Spam
– Theme Check
– zbPlayer (for playing mp3 audio files)

I think I’ve addressed everything you said in your last post. And, again, my apologies for the confusion and my sincere thanks for helping me sort this out.

Ok then disregard that. I was just going by your thread history and it looked like that issue had come up a few times.

I just discovered that simply turning the Security Logging function on or off will cause the root folder .htaccess file permissions to revert to 0644.

Ok looks like we will need to add locking for Security Logging On/Off in BPS free. It is hard to keep track of what the 2 different plugins are doing or not doing. ??

I don’t think any of those plugins would do anything with htaccess files so it does not appear to be a plugin issue and after the additional info you posted I think this is just some sort of procedural thing we need to double check. ie Security Logging On/Off needs to have autolocking added to it.

AutoLocking has been added to Login Security On/Off forms in BPS .50.9 – thread has been resolved.