Proxy: Software Update does not request authentication and fails

RESOLVED FIXED in mozilla1.8final

Status

()

Toolkit
Application Update
--
major
RESOLVED FIXED
13 years ago
9 years ago

People

(Reporter: Anthony Bongaards, Assigned: Darin Fisher)

Tracking

({fixed1.8, relnote})

unspecified
mozilla1.8final
fixed1.8, relnote
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [asaP1])

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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

Comment 1

13 years ago
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

Comment 2

13 years ago
(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

Comment 3

13 years ago
*** Bug 266673 has been marked as a duplicate of this bug. ***

Comment 4

13 years ago
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?

Comment 5

13 years ago
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...

Comment 6

13 years ago
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.

Comment 7

13 years ago
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. ***

Comment 9

13 years ago
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

Comment 10

13 years ago
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

Comment 11

13 years ago
(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?

Comment 12

13 years ago
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?

Comment 13

13 years ago
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.

Comment 14

12 years ago
This bug also happens if there´s an extension that requires a connection like
Gmail Notifier.
Flags: blocking-aviary1.1? → blocking-aviary1.1+

Updated

12 years ago
Whiteboard: [asaP1]

Comment 15

12 years ago
Regardles to this bug, you can still using software update. First open any webpage 
and authorize the proxy, and then run the update feature.

Comment 16

12 years ago
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

Comment 17

12 years ago
*** Bug 290944 has been marked as a duplicate of this bug. ***

Comment 18

12 years ago
->darin for triage.
Assignee: bugs → darin
(Assignee)

Comment 19

12 years ago
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
(Assignee)

Updated

12 years ago
Depends on: 297951

Updated

12 years ago
Flags: blocking1.8b4?

Updated

12 years ago
Flags: blocking1.8b4?
Flags: blocking1.8b4+
Flags: blocking-aviary1.1+
(Assignee)

Updated

12 years ago
Flags: blocking-aviary1.1?

Updated

12 years ago
Flags: blocking-aviary1.1?

Comment 20

12 years ago
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-
(Assignee)

Updated

12 years ago
Flags: blocking-aviary1.5?

Updated

12 years ago
Flags: blocking1.8b4-
Flags: blocking1.8b4+
Flags: blocking-aviary1.5?
(Assignee)

Comment 21

12 years ago
Created attachment 192413 [details] [diff] [review]
v1 patch
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+
(Assignee)

Comment 23

12 years ago
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?

Updated

12 years ago
Attachment #192413 - Flags: approval1.8b4? → approval1.8b4+
(Assignee)

Comment 24

12 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Keywords: fixed1.8

Comment 25

11 years ago
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.

Comment 26

11 years ago
I think that bug 268071 should have been duped to bug 312473 instead.  Agree?

Comment 27

11 years ago
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.