857537 - Request password of proxy when entering Private Mode

Status: UNCONFIRMED

(Core :: Networking: Proxy, defect, P3)

Description

[ru-vadik]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130326150557

Steps to reproduce:

Open new window in Private Mode.


Actual results:

Request password of proxy when entering Private Mode. See http://www.youtube.com/watch?v=AsZ9PJFFozw&feature=youtu.be


Expected results:

Must use stored password from the password manager without asking

Comment 1

[Josh Matthews [:jdm]]

Honza, I'm pretty sure this is due to the split authcache for private vs. public connections. Can you think of any way to handle this in a sensible fashion?

Comment 2

[Honza Bambas (:mayhemer)]

(In reply to Josh Matthews [:jdm] from comment #1)
> Honza, I'm pretty sure this is due to the split authcache for private vs.
> public connections. Can you think of any way to handle this in a sensible
> fashion?

Sorry for very very late answer here.

Technically it's simple to modify nsHttpChannelAuthProvider::AddAuthorizationHeaders() to use non-private cache when adding auth headers for proxy.  Login manager is using saved passwords even in PB windows, so that should "just work" even when user connects the proxy the first time.

Comment 3

[Josh Matthews [:jdm]]

Good point. It's a simple matter to obtain a pointer to the public authcache (see http://hg.mozilla.org/mozilla-central/annotate/630974b4fa14/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#l176) and pass it to the first SetAuthorizationHeader call.

Comment 4

[Sudheera Palihakkara]

Is there anywork to do here? as far as I understand it some sode editing has to be done, If it is the case I'll be happy to work on this.

Comment 5

[Josh Matthews [:jdm]]

I explain the changes required in comment 3. Let me know if anything is unclear.

Comment 6

[Honza Bambas (:mayhemer)]

The code patch it self is a two line change.  However, it needs a test.  That may be a bit more tricky to create.  We have tests [1] for various auth cache/auth dialog scenarios, so that test could be just extended.  

[1] http://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/test/test_prompt_async.html?force=1

Comment 7

[Michael Hoffmann]

Hi, I've been trying to figure out how to test this. I'm new to mozilla so I've been reading the code and trying to figure things out myself here.

The test referred to uses iframes in one window, and to not deviate from that behavior I first tried to investigate if it's possible to load the contents of an iframe in private browsing mode. I was thinking about enabling private browsing on the docshell for one iframe for example, and while there is an accessor method for setting that, it seems like it's not accessible from javascript.

The next approach I tried was to open a new window with openDialog(), where it's easy to enable private browsing. This new window could then load a html-file containing an iframe, and in that iframe the authenticate.sjs could then be loaded. The result of that request could then be passed back to the calling test through 'opener' for example.

I got a little further with that approach, but since my local html-file was affected by the proxy authentication, it also popped up a passwod dialog. And since this blocks when calling openDialog() this dialog is not handled by the test like the other dialogs. So now I think I need to ask for some guidance.

Should I continue with any of these approaches, or is there a better way to solve this?

Comment 8

[(no longer active)]

Honza is probably the best person to ask your question, Michael.  Thanks for looking into this!

Comment 9

[Honza Bambas (:mayhemer)]

Michael, could you please attach any WIP patches (in what ever, but compilable state) you have?

Are you running an existing test, just in a PB window/iframe?  If so, which one?  And another "if so:" the test should behave the same way when you first delete the auth cache and stored logins in LoginManager.

But that doesn't completely check fix of this bug: we want to know that in PB mode proxy auth will not pop up.

I think a separate (new) test would be better.  Just do a test for proxy and http auth (two dialogs for non-PB and one dialog for PB).  Abstract existing tests.  Using authenticate.sjs is the right way to do.

Comment 10

[Michael Hoffmann]

(In reply to Honza Bambas (:mayhemer) from comment #9)
> Michael, could you please attach any WIP patches (in what ever, but
> compilable state) you have?

I really don't have anything worth showing at this moment because I was mainly trying to just get a private window up and running.  I didn't get that far that I could actually try a real test.

> Are you running an existing test, just in a PB window/iframe?  If so, which
> one?  And another "if so:" the test should behave the same way when you
> first delete the auth cache and stored logins in LoginManager.
> 
> But that doesn't completely check fix of this bug: we want to know that in
> PB mode proxy auth will not pop up.
> 
> I think a separate (new) test would be better.  Just do a test for proxy and
> http auth (two dialogs for non-PB and one dialog for PB).  Abstract existing
> tests.  Using authenticate.sjs is the right way to do.

Thank you for showing the way forward!  I started looking into this, but got distracted by a bug preventing me from running the test_privbrowsing_perwindowpb.html test.  I have now filed a report, see bug 883125.

But now that I know that I can't run some tests unmodified on my computer this issue is a little harder.  But I'll let you know if I make any progress :)

Comment 11

[Josh Matthews [:jdm]]

I am not a great mentor for this bug, since I don't know much about the test changes required nor how to set up a proxy for manual testing.

Comment 13

[Matthew Jurgens]

Is anyone still working on this. I still have this problem as originally reported.

Comment 14

[Michael Hoffmann]

(In reply to Matthew Jurgens from comment #13)
> Is anyone still working on this. I still have this problem as originally
> reported.

Sorry, I think I got distracted and then didn't continue working on this bug.

Comment 15

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 16

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 17

[BMO Automation]

Moving bug to Core/Networking: Proxy.