in netscape 4 it is possible to remove the username and password stored for basic auth, by entering false login information at the prompt. when you hit [ok] netscape will subsequently try to use that false information to log in, and thus fail. mozilla will continue to use the last username and password that worked successfully, making it impossible to remove that information without quitting the browser. tasks -> privacy and security -> password manager -> log out does not remove any stored basic auth information and neither does tasks -> privacy and security -> password manager -> view stored passwords show the basic auth information that mozilla has currently in memory
See bug 55181 for an rfe for having a basicauth logout.
*** This bug has been marked as a duplicate of 55181 ***
REOPEN: this would be fixed by the RFE, but it is actually a possible 4xp bug.
> REOPEN: this would be fixed by the RFE, but it is actually a possible 4xp bug. Shouldnt the RFE be 4xp then? And, the method described in the bug for make nn 4 "logout" is really a workaround, not a feature of nn 4. (imho)
They aren't the same thing. If this worked in Communicator and not now, then it's "4xp". It doesn't matter if it is correct or incorrect behavior (from a standards perspective). Some sites offer logout out, which is smart, because you can't assume a browser will offer to dump credentials, (or do this correctly).
As far as I can see it never "worked" in communicator, there just was a workaround to do it. But you're the boss. (= (removing myself from cc list)
I don't quite follow. In the password manager you can remove a login. Even though Netscape 4 did it differently, this is a clear way to do it. I'd go for WONTFIX. pi
You can't remove a basic authentication auth token via password manager. This bug is about basic authentication auth tokens.
In an e-mail discussion with the reporter I could not reproduce the problem. Can someone provide a testcase (including login/password for testing) with exact steps to reproduce? pi
You need a site that for some reaons sends a 401 after you sent a good authed request. Probably the easiest way to do this is to configure a web server that has no auth caching and: 1- Request protected page. 2- Get user:name password challenge, enter correct info. 3- Change password on server backend. 4- Request same page again. Your browser will automatically send the old username and password, but the server will reject it because it does not match. 5- Receive another challenge. 6- Change password back to previous value on server side. 7- Hit enter (to try to clear the value in the client) Likely observed behavior, (if I read the reporter correctly) is despite your attempt to clear the value, it still sends the old values to the server.
this bug was reported in february 2001. more than a year ago!! it was marked a duplicate of bug #55181 in march of that year. i did not pursue the issue any further as #55181 is actually the correct solution to the issue in general, and i was confident that it would be implemented by the time 1.0 is released. eventually i totally forgot about this bug, and only thanks to boris i looked into the bug again now and had to notice that it is not even reproducable with 1.0. hence the bug has been fixed somewhere between 0.8 and 1.0 i had totally forgotten about the bug presumably because it may have been fixed much earlier than 1.0
Verified that this part is fixed - "and neither does tasks -> privacy and security -> password manager -> view stored passwords show the basic auth information that mozilla has currently in memory" You can now delete stored passwords created during the same session. This part - "tasks -> privacy and security -> password manager -> log out does not remove any stored basic auth information" is a duplicate of bug 55181 which is still open.