I just tried logging into one of my sites that I’ve password protected, and I stupidly used the wrong password multiple times. Now when I go to the site, I don’t get a username/password box. Instead, I just get a 403 error. Does the server somehow keep track of failed logins from a given IP and block it? If so, how do I fix it?
[Update a few minutes later]
OK, more clues. When I attempt to log in from my laptop, I get a username/password box, but when I correctly type in username/password, I get the same 403 error. This tells me there’s something going on with the server. Right?
One other bit of info. I can log in to other sites that use the same username/password, just not this one. Is it an Apache issue? If so, I’ll have to talk to support at my host. I don’t understand that, though, because it’s just for this one directory. It seems like a .htaccess problem, but I didn’t know that it would block an IP after a failed attempt, and I can’t find any info about how to unblock it.
[Wednesday morning update]
Well, it let me in this morning, so it must have had a time limit on the lock.
This may sound simplistic, but try to log in from “somewhere else”. The public library comes to mind.
There is not a doubt in my mind that I could log in from somewhere else. I want to log in from here.
Though that does at least lead me to a diagnostic — I should see if I can log in from my laptop. That would tell me if it was an IP problem, or a computer (or browser) problem. Which means that at least a temporary solution might be to install Opera and try that.
If it is a browser problem, you can probably fix it by removing the offending saved password for the website.
That’s what I was thinking, but I couldn’t find where Firefox saved passwords. But as I noted in follow-up, it’s not a browser problem. It looks like an IP problem.
If you have ssh access you can remove/rename .htaccess to see if that’s the issue. With us the standard mod_auth setup does not include any sort of IP-banning capability.
OK, I moved .htaccess to .htaccess.bak, but no joy.
Part of me wonders whether something happened like it created a file that hadn’t existed before to store the blocked the IP address, but it created it with a funny permission. I once ran an Apache server in a directory created and owned by root, but the process ran as the user “apache”, so the file access permissions were always a bit weird. I can imagine a failure to access a file used in the authorization process might manifest as a 403, depending on the implementation.
Have you tried doing a real refresh of the page? Back in the day, Netscape had two versions of page reload. One tended to just read from cache, and a different key sequence would force the browser to ask for the page again. IIRC in IE, the same thing was accomplished by hitting Ctrl-F5 instead of just F5.
You’re going to have to talk to the webhost. If it were an HTACCESS problem, you wouldn’t get the login box because that’s the same URL.
It’s very likely that the problem is data cached in the authentication module, denying access by IP to shutdown password cracking attacks. That data is not stored in the HTACCESS file. Either it will time out after a while, or you’ll have to talk to the ISP. But
I second AOG. Tech support at my host gets the cold sweats when they see my account name on a query, but they do solve the problems quickly.
Almost like they want to…
FWIW the passwords in Firefox can be accessed from:
Tools->Options->Security->Saved Passwords