59609 - Password manager: Proxy auth linked to target site (!proxy server)

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P3)

Description

[Koike Kazuhiko]

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.

Comment 1

[Jacob Steenhagen]

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.

Comment 2

[Gervase Markham [:gerv]]

Dupe, I think...

Gerv

*** This bug has been marked as a duplicate of 57291 ***

Comment 3

[Jacob Steenhagen]

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).

Comment 4

[Jacob Steenhagen]

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

Comment 5

[Darin Fisher]

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.

Comment 6

[Jacob Steenhagen]

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

Comment 7

[Darin Fisher]

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.

Comment 8

[Darin Fisher]

added keyword arch.

Comment 9

[Ben Bucksch (:BenB)]

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?

Comment 10

[Darin Fisher]

Rest assured, the HTTP spec is not the problem.

Comment 11

[Christian Schmidt]

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? 

Comment 12

[Darin Fisher]

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

Comment 13

[Ben Bucksch (:BenB)]

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)?

Comment 14

[Darin Fisher]

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.

Comment 15

[benc]

mass move, v2.
qa to me.

Comment 16

[benc]

Should this go to networking or wallet?

Comment 17

[Christian Schmidt]

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?

Comment 18

[Christian Schmidt]

Attachment: Patch suggestion

Comment 19

[benc]

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.

Comment 20

[Darin Fisher]

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!

Comment 21

[Christian Schmidt]

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.

Comment 22

[Darin Fisher]

yes

Comment 23

[Darin Fisher]

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

Comment 24

[benc]

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.