All users were logged out of Bugzilla on October 13th, 2018
1.88 KB, text/plain
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:22.214.171.124) Gecko/20060111 Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:188.8.131.52) Gecko/20060111 Firefox/184.108.40.206 When I login to a site, I get the standard .htaccess login box, after I login, I am then redirected to another URL, which is also .htaccess protected, then I am redirect to a URL within that login. It will save the session, but as soon as the session ends I must re-login. It's the same password for both, but firefox will not save that second login. I manually put it in signons.txt and it works, once. Then it times out and I have to login again. If I go directly to the second URL it also works, but not when it redirects. I'm not exactly sure why that is the case, but that appears to be what is happening. Thank you for your time! ben Reproducible: Always Steps to Reproduce: 1. Login to .htaccess protected dir 2. Get redirected to second .htaccess protected URL 3. Login, wait for timeout, will not save passwd for second login. Actual Results: Logged out. Expected Results: For firefox to save the password.
Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!
Whiteboard: CLOSEME 06/27
Version: unspecified → 1.5.0.x Branch
I do still see it, but it's not a redirect causing it. Something specific to an internal work site. On FF2's initial startup, it will save the password, after a while, it seems like there is a timeout and you have to log in again. But the password is never saved. I'm not sure what information I'd have to provide for you to able to trouble shoot this, I could get some info from livehttpheaders if that would help. I wish I could just show you the site, but unfortunately it is internal. IE doesn't save the password either, if that means anything. Thank you!
If IE doesn't save the password either, then I guess the website is denying browsers from doing such a thing, so it's expected behaviour, so this bug is INVALID. Thanks!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
Whiteboard: CLOSEME 06/27
Hmm, I want to better understand the problem here before closing this out. I'd like to think we have a higher standard than parity with IE. :) Submitter, info showing the sequence of HTTP requests / replies would be very helpful. I think LiveHttpHeaders or FireBug should be able to show that. A network sniffer should also do the job, unless it's not SSL. If you could attach (or email) a censored version, that would be great.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Steve, IE does save it for several interations, then drops it. This could be an IE bug, I'm not up on it's exact behavior. But how does a site deny browsers from saving a password? Btw, these are not fields on the website, this is more of the .htaccess, pop up for authentication, what is that 401? I can manually make a auto-login for it, by editing where FF stores logins, and it works, but only for one interation. Then there is a timeout, and the login request comes up again, but it is blank. Should not FF2 simply fill out the fields, since they never change? Justin, I will do this as soon as possible, probably tomorrow. Thanks! I assume you just want the login sequence?
(In reply to comment #4) > Submitter, info showing the sequence of HTTP requests / replies would be very > helpful. I think LiveHttpHeaders or FireBug should be able to show that. A > network sniffer should also do the job, unless it's not SSL. If you could > attach (or email) a censored version, that would be great. There should be a censored version of the login attached, I attempt to hit a page, get a 401, type in my login, get a 200. A cookie is set, which I believe expires, thereby logging me out after a set time. However, I must always type my password in FF1 or FF2. When I go to tools -> options -> security -> show passwords, I clearly see a login and password for this domain. In IE, it will sometimes old the password in the box when you check to retain it for several cycles of timeouts, but eventually will "lose" it. FF2 never holds it. With the exception that if you close the browser with the tab open, and restart it, it attempts to reopen the tab and usually has the fields filled in. Although, not always, I think it depends on whether I have checked to retain the password the last time it asked. Because it never retains it, I have mostly stopped checking the box. I can go find the file where it retains the passwords and dump that, censored, as well, to prove to you that there is indeed an entry for this site I am hitting, but it is not filling out the 401 fields like, imo, it should. I have even manually added an entry to this file, which causes the fields to be filled out on the next page load (i.e. I thought I had it fixed) until the next time out, when it refuses to fill out the login fields again. Thank you again for looking into this! I hope I have made sense here, let me know if I should provide any more information. Ben
Created attachment 267585 [details] Short login sequence to a site where password is not being stored.
It looks to me like what's going on is that the server has decided it wants to expire your login. The first request in attachment 267585 [details] show that there's already an Authorization header in the request, so you've already authenticated to the server (or at least got a prior 401 and entered a username/password). The 401 includes |WWW-Authenticate: Basic realm="realm_name"|... Is the realm_name always the same in the 401 replies? [I'm assuming you've censored the actual values.] Firefox keys a login to a specific realm, so if the realm is different it won't fill in an existing login. There may also be some interaction with bug 379997 here, which causes password manager to delete logins that have failed. That would explain why logins you add manually amight be disappearing.
Yes, realm name is always the same. And FF is keeping a login to this specific realm. What's strange is I can go to password manager and see the login, it's always there. I will check again that the realm name matches. I think this is on the right track though, the server must be generate something unique each time, so that FF does not recognize it can reuse the password it has stored. Of course, if I choose to store it 10 times in a row, it is still only stored once. Very puzzling! Is there anymore info I could provide?
The password is stored like this in the FF2 save logins file : ==========START============= sub.site.net:80 (realm_name) [long string] * [long string] . ===========END============ And if I close FF2, even if I clear cookies and close it, when I re-open it, the password is saved, and auto-fills in the 401 request. The only thing that seems to remove the password is when the session times out. I don't think this is correct behavior since regardless of what the server wants, I have instructed FF to retain this password indefinitely.
This is still not working. Forget the redirect stuff, has nothing to do with it. I go directly to the page. The first time I hit it, the login prompt comes up, with the basic HTTP Auth form filled out. After the "timeout" (not sure what determines it) the basic HTTP auth box comes back up blank. No matter how many times I tell it to save it. First visit always loads the saved username/passwd. After the timeout, it's blank. Any more ideas? I'm testing firefox 3 (beta) at the moment.
Ok, this appears to be saving passwords correctly in firefox beta3. Even during timeouts via HTTP basic auth, it saves. Thanks a lot for fixing it!!!!!!!!!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago → 11 years ago
Resolution: --- → FIXED
(In reply to Steve England [:stevee] from comment #1) > Reporter, do you still see this problem with the latest Firefox 2? If not, > can you please close this bug as WORKSFORME. Thanks!
You need to log in before you can comment on or make changes to this bug.