Closed Bug 259429 Opened 17 years ago Closed 16 years ago

Proxy: Software Update does not request authentication and fails

Categories

(Toolkit :: Application Update, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.8final

People

(Reporter: swtd, Assigned: darin.moz)

References

Details

(Keywords: fixed1.8, relnote, Whiteboard: [asaP1])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10

When you click the "Check Now" button under Software Updates, it fails if behind
a proxy server. The work around is to go to a web page that requires the browser
to log you into a proxy first. If you do this then go back and click "check Now"
it works.

Reproducible: Always
Steps to Reproduce:
1. Open Firefox behind a proxy server that requires authentication
2. Click Tools, Options
3. Navigate down to Software Updates and click Check Now
4. Connection fails instantly

Actual Results:  
Recieved an error message

Expected Results:  
It should bring up the proxy authentication login box, and after sucessful
username/password entered, check the update server and report results
Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10

This also applies to using the extension update functionality.

To reproduce, change step 2 and 3:

2. Click Tools, Extensions
3. Select an Extension, and click Update

(In reply to comment #0)
> When you click the "Check Now" button under Software Updates, it fails if behind
> a proxy server. The work around is to go to a web page that requires the browser
> to log you into a proxy first.

I also saw this bug while attempting to upgrade some kiosk-type computers I
manage that use the "AutoHide" extension on an intranet to 1.0PR (from 0.9.3). 
On the first run it asked me to run software update to update that extension,
but it failed.  I tried the above workaround and got it to work when running
software update manually.  This could be a big issue for seamless upgrades in a
corporate environment.

Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
*** Bug 266673 has been marked as a duplicate of this bug. ***
Confirming. This is a big problem for all company intranets using
password-protected proxies: The worst case scenario is that Firefox won't ever
be updated, because users are not aware of this bug and don't know how to
trigger the update manually... Since this prevents us from deploying security
updates, setting severity to Major.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.0?
dveditz, do you have any idea what causes this bug? Darin said "most likely the 
networking layer is not being supplied with a nsIAuthPrompt to use"... Perhaps
you could have a quick look at this. If a fix is easy, it could make Firefox 1.0
much more usable in corporate environments...
Saw also this bug on Firefox (up to 1.0RC1) in a managed Windows domain
(proxy.pac,...) with a very susceptible Squid proxy (doesn't allow to go to a
website if the url is not complete : especially if missing the first "www.". can
lock dead firefox for a minute!)

Even once authentified, the update agent cannot access to extension, themes and
browser upgrade list. Very annoying.
no patch in sight, not gonna happen for 1.0. 
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Whiteboard: firefox release notes candidate
*** Bug 268071 has been marked as a duplicate of this bug. ***
https://bugzilla.mozilla.org/show_bug.cgi?id=260476

This bug might be a duplicate of this. It was repored by me.
Keywords: relnote
Whiteboard: firefox release notes candidate
The problem is that (as best as I can describe it), every consumer of necko
needs to implement the proxy auth UI support. People want to call Necko and make
it all the work, but necko does not do this UI for various technical reasons.
Everytime someone adds a network function, they always seem to forget this. it
has happened so many times before, I can't remember the modules that had this
problem, except, oh yeah, Netscape Activation (because it crashed everytime a
407 came back).
QA Contact: bugs → benc
Summary: Software Update does not request proxy authentication and fails → Proxy: Software Update does not request authentication and fails
(In reply to comment #10)
> The problem is that (as best as I can describe it), every consumer of necko
> needs to implement the proxy auth UI support.

benc, can you provide any pointers on how to find the piece of code where this
bug could be fixed, e.g. which interfaces/methods are involved?
Asking for blocking-aviary1.1, because 1.1 is categorized as a
bugfixing/polishing release, and should probably fix those bugs that are
mentioned in the 1.0 release notes.
Flags: blocking-aviary1.1?
Extensions will not install, I ahve checke the 'Too' 'Web' presferences, and the
option to allow sites to install software is enabeled.  Any ideas will be helpful.
This bug also happens if there´s an extension that requires a connection like
Gmail Notifier.
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Whiteboard: [asaP1]
Regardles to this bug, you can still using software update. First open any webpage 
and authorize the proxy, and then run the update feature.
This happens also without password auth, but not in all cases, first time I seen
this bug in 1.0.3, thunderbird 1.0.2 has the same bug
*** Bug 290944 has been marked as a duplicate of this bug. ***
->darin for triage.
Assignee: bugs → darin
I think this will still be an issue with the new update system.  We don't
exactly want to prompt users when we auto-update, but we do want to prompt them
when they explicitly invoke the update system.
Blocks: 290390
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: --- → Firefox1.1
Depends on: 297951
Flags: blocking1.8b4?
Flags: blocking1.8b4?
Flags: blocking1.8b4+
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1?
This is definitely something that we'd like to see in terms of ensuring we have
a strong enterprise feature set.  The workaround is clunky.  Deferring for
1.8b4, need to revisit and determine action plan and assign resources for 1.5 or
2.0.

/cb

Flags: blocking1.8b4+ → blocking1.8b4-
Flags: blocking-aviary1.5?
Flags: blocking1.8b4-
Flags: blocking1.8b4+
Flags: blocking-aviary1.5?
Attached patch v1 patchSplinter Review
Attachment #192413 - Flags: review?(cbiesinger)
Comment on attachment 192413 [details] [diff] [review]
v1 patch

+      var prompt =
+	   Components.classes["@mozilla.org/network/default-auth-prompt;1"].
+	   createInstance();
+      return prompt.QueryInterface(iid);

could write this:
  return
	  Components.classes["@mozilla.org/network/default-auth-prompt;1"].
	  createInstance(iid);

either way, r=biesi
Attachment #192413 - Flags: review?(cbiesinger) → review+
Comment on attachment 192413 [details] [diff] [review]
v1 patch

Yeah, I considered writing the more compact form as well.  I preferred this way
for readability, but maybe the 'tighter' code is better.

Anyways, this is a pretty trivial and low-risk fix that would be nice to get in
before we branch.
Attachment #192413 - Flags: approval1.8b4?
Attachment #192413 - Flags: approval1.8b4? → approval1.8b4+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Keywords: fixed1.8
Is this fixed in Firefox 2.0?  The comment says it's only fixed on the trunk, but the keyword says fixed1.8. :-s

There is a similar issue (bug 268071) that was duped to this one that certainly isn't fixed in Firefox 2.0.
I think that bug 268071 should have been duped to bug 312473 instead.  Agree?
Sorry, the chain of dupes here suggests nobody really understands what's going on.

I think the fix for each of them will be similar, but I doubt fixing one automatically fixes the other.

I think there are four separate issues:
1. Software Update doesn't work if proxy requires authentication and not already authenticated
   Bug 259429 (This one, should be fixed in Firefox 2.0 as far as I can tell)

2. Extension Update doesn't work if proxy requires authentication and not already authenticated (e.g. at startup before main window is shown)
   Bug 359940 (wrongly DUPED to 312473), Bug 268071 (wrongly DUPED to 259429)
   Could be two cases:
   - Before main window is shown
   - After main window is shown but before user has authenticated to the proxy

3. Extension Update doesn't work if target link requires HTTP authentication
   Bug 312473

4. Live bookmarks don't work if proxy requires authentication and not already authenticated (e.g. if home page is about:blank)
   Bug 260476

Can somebody sort this mess out?

I propose:
- Reopen 268071
- Redupe 3559940 to 268071
- Not adding any further spam to 259429 :-)
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.