From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/00200203 BuildID: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/00200203 When I use HTTP Authentication and then I "log out" i.e. next time I load the page browser receives 401 and if I type another username it is still using the old one and the old password to authenticate. The only way to log in using different username is to restart the browser Reproducible: Always Steps to Reproduce: 1.Login using HTTP Authentication. 2. Logout, so the next time browser receives 401. 3. Login using different uname/passwd pair. Actual Results: I logged on as a previous user not the one I wanted to. Expected Results: Log me in as the user I've specified.

So... we _do_ put up a dialog, but then do _not_ send the data you entered in that dialog?

Yes it does show a popup but uses the previous values i.e. I type user/password the first time then I "log out" and next time browser gets 401 then I type username2/password2 and when I am logged in I realise that I am logged as user/password. i.e. the previous one not the new username2/password2 I've typed in.

To HTTP networking.

mass futuring of untargeted bugs

resetting target milestone; that should be set by the developer. Nominating, however. This bug makes it possible to log in with a certain set of credentials while thinking that you are logged in with a different set...

This looks like a dup of bug 137852 ... agreed?

http://www.viewline.net/ Mozilla doesn't acknowledge login information request by the ASP and this generate a 401.2 error instead of 401.1 -> i submit a new bug. mark it as DUPEME. mark it as blocking bug 12578 and bug 57529 Bug 134103 and this sorry for the spam

adt: nsbeta1+/adt2

(I thought we dould have lots of dupes of this... time to go looking...)

bz & darin: this bug is plussed, and depends on an un-plussed bug. What do you want to do here? There are a lot of different descriptions of what sounds like the same prolem, which is really "HTTP's cached auth takes precedence over everything". If we are going to muck with this, it sounds like we'd want to solve all the problems at once...

ADT: Nominating topembed

Darin, Can you take a look at this and are the blocking and depends on comments acurate?

ok, this bug is very old. what we need is for someone to confirm this bug against mozilla 1.4 beta. if the bug can be confirmed then we'll need to proceed from there using mozilla 1.4 beta to test against. Timofej: can you please give mozilla 1.4 beta a try and get back to us? thanks!

I'll try to dig up a system when I can change the passwords on the fly. The problem of trying to change the user:pass info in cache via an HTTP URL is still happening, but that might be a higher level problem.

UPDATE: WFM, Mozilla 1.4b, Mach-O, Linux. STEPS: Connect to admin server, which requires basic auth. Auth successfully. Change admin password. (this invalidates currently cached auth). On next page request, auth is requested again. Enter new password. EXPECTED/OCCURRING behavior: loging successful. I've sniffed the session to see that the admin server sends a new 401 after the password change, so this looks like it is working. I did find problems when playing w/ URL embeded passswords, so I think the other problems (like composer related problems) will need further analysis.

ben said wfm. please reopen if someone continues to see this problem with 1.4rc1 or later.

VERFIED/WFM.