Password for proxy server is stored for another site. (1) Set proxy server which needs authentification. (2) Access somewhere. ID and password are required for proxy. (3) Open password manager. Password is stored for the server which you accessed first after you set http proxy.

I've noticed this before as well... this has the unfortunate sideeffect that if you visit a website other than your normal first, the username/password info in not already filled in.

Dupe, I think... Gerv *** This bug has been marked as a duplicate of 57291 ***

As I understand it, this is not a duplicate... bug 57291 is about requiring an auth each time a web page is visted... this one is about how it get's stored in Password Manager. Even tho it's stored as being for the first web page visted, the password is still sent to the proxy server for each and every web page (as it should be).

This also results in issues as described in bug 42952 with the sidebar.

The problem is that the callback from HTTP for proxy auth is not distinguishable from regular server auth. HTTP just asks for a username/password dialog via nsIPrompt::PromptUsernameAndPassword(). The password manager which intercepts these callbacks has no way of knowing that this auth is for a proxy server and not the content server. This is a known problem that can only be resolved by an API change to HTTP.

Is this "known bug" the one where mozilla should use the "realm"?

Jake: not sure exactly what you mean... the realm bug was fixed (bug 32335). This is different. The nsIPrompt interface doesn't allow the necko HTTP impl to indicate to the implementer of nsIPrompt that the auth is for a proxy server and not an origin server. Hence the confusion on the part of password manager.

added keyword arch.

I hope the nsIPrompt API is not declared stable? That's only a Mozilla-internal problem, not a problem in the HTTP datastream (i.e. HTTP proxy spec), right?

Rest assured, the HTTP spec is not the problem.

Darin Fisher wrote: > The password manager which intercepts these callbacks has no > way of knowing that this auth is for a proxy server and > not the content server. Suggestion (by someone not hacking on Mozilla): Is it really necessary for the password manager to know whether a callback comes from a proxy server or a content server? In NS4, when I am prompted for username/password for my proxy server, the dialog says "Proxy authentication required for MyProxy at proxy.myisp.com:5555". In Mozilla, the dialog says "Enter username and password for MyProxy at www.somesite.org". If the hostname+port+realm of the proxyserver is sent to nsIPrompt::PromptUsernameAndPassword() instead of the requested site (imo that gives a more logical prompt as discussed in bug 52616), wouldn't that store the password right in Password Manager?

Christian: I agree with your suggestion. This is an easy fix that should do the job. Thanks!

I don't fully understand the suggestion, but can it happen that a password for site a is automatically sent to site b, if I told Mozilla to automatically log in and the realm happens to be identical for the 2 sites (is that possible)?

That would not happen. During a session, HTTP keeps a "cache" of valid authentication strings that can be used for future HTTP transactions with the same server for content in the same HTTP realm. This cache goes away when mozilla shuts down. The password manager remembers passwords entered by the user. There is a passwordRealm parameter on nsIPrompt::PromptUsernameAndPassword() that it uses as a key into its table of passwords. The suggestion was to adjust the passwordRealm parameter to hold the proxy server's host name instead of the content server's host name for proxy authentication.

mass move, v2. qa to me.

Should this go to networking or wallet?

I know I belong to a very small minority that uses a proxy server that requires authorization, but it was still a disappointment to see "Target Milestone" changed to "Future". So I decided to try to fix the bug myself. This is the first time I submit a patch to Mozilla, so please help me doing things right. The patch consists of two parts: One that changes the message in the username/password prompt, and one that changes the url that is sent to PromptUsernameAndPassword which is the one that is used by Password Manager to store the password. I create an URL that represents the proxy like "http://proxyhost:proxyport". This is probably a minor hack but I guess it is ok. Currently the port number is not shown in the password prompt, for neither regular nor proxy auths. In NS4 it is. Should this be changed to reflect NS4 behaviour?

Showing the port is desirable to me, because http proxies are homeless, and run on 8080 by a sort of bad lingustic joke (80+80). RFC 1700 shows that no ports in the 8xxx range are actually reserved: fodms 7200/tcp FODMS FLIP fodms 7200/udp FODMS FLIP man 9535/tcp man 9535/udp So, I think displaying a port is a very good idea.

christian: the patch you submitted seems to be against the old http code. as much has changed in http since mozilla0.9, please verify this bug against a recent nightly build. thx!

Darin: you are right. Much has changed, and appearently this bug has been fixed. The password now seems to be stored in Password Manager just right. The realm for the proxy server is also shown in "View Stored Passwords" in Password Manager. However, the realm for the proxy server is not shown in the username/password prompt. I guess this should be filed as a seperate bug.

yes

marking WORKSFORME since i'm not sure what exactly fixed it.

reporter: This bug is a "futured" or "untargeted" bug which has been "resolved/works for me". Most bugs meeting this criteria are usually somewhat out of date or working in the current builds. If this bug is not happening for you in a recent build (such as the Mozilla daily build, Mozilla 0.9.3, or Netscape 6.1), please use the friendly "Mark bugs as VERIFIED" radio button to set this bug to "VERIFIED/WORKS FOR ME" If you reported the bug on a platform (e.g. Linux) and other contributors reported on another platform (e.g. Mac OS), please comment that it works for you but do not verify it yet. For these multi-platform bug reports, we need to verify all reported platforms -OR- create new "still broken on platform X" bugs when you verify.