extension update does not try authentication if needed (e.g. proxy auth at startup)

RESOLVED FIXED in mozilla1.9alpha6

Status

Core Graveyard
Installer: XPInstall Engine
P2
normal
RESOLVED FIXED
12 years ago
a year ago

People

(Reporter: Christian Schaefer, Assigned: mossop)

Tracking

({fixed1.8.1.5})

1.8 Branch
mozilla1.9alpha6
x86
Windows 2000
fixed1.8.1.5
Bug Flags:
blocking1.8.1 -
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

if an extension on a server is protected via http authentication the automatic
update function of the extension manager will fail giving the following error
message:

	Firefox could not install the file at
	http://www.homeofmyext.com/myext.xpi
	because: Not a valid install package

I would expect the usual authentication request dialog to popup and the update
to fail only in the case that the authentication fails.

Reproducible: Always

Steps to Reproduce:
1. install an extension from a server that you control.
2. protect the xpi file with http authentication suing ie a .htaccess file
3. in the extension manager try 'find update'
4. if there is an update available (you'll have to make sure of that of course)
hit update

Actual Results:  
the update will fail giving this (rather unspecific) error message:

	Firefox could not install the file at
	http://www.homeofmyext.com/myext.xpi
	because: Not a valid install package


Expected Results:  
it should have opened a common http authentication request dialog to enter
username and password and update the extension as soon as the authentication is
sucessful or fail giving a useful message if the authentication failed.
Do you have a need for this?
(Reporter)

Comment 2

12 years ago
> Do you have a need for this?

well yes I have indeed.
I currently develop an extension for a client. this extension is used as an
administrational tool for the clients website and therefor should not be
publically available. the client however may chose a number of employees that
are allowed to have access to that extension.
now the easiest way to provide software updates is using the update mechanism of
the extension manager. but as long as the http authentication is not working I
can see no way to benefit of the ease of that mechanism while maintaining a
strict security level.

now just to assure you of my appreciation of extension building: next to the
extension itself I write a report of the developing process explaining my
problems and the solutions I found. this of course will be publically available
as soon as the extension is released to the client.

thanks a lot!
/christian
Status: UNCONFIRMED → NEW
Ever confirmed: true
Daniel, this needs to happen in XPInstall unless I am badly mistaken.
Summary: extension update does not try authentication if needed. → extension update installation does not try authentication if needed.
XPInstall performs the download and needs to prompt for authentication when needed.
Assignee: nobody → xpi-engine
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Core
QA Contact: extension.manager
Version: unspecified → 1.8 Branch

Comment 5

11 years ago
-> me
Assignee: xpi-engine → darin

Updated

11 years ago
Status: NEW → ASSIGNED
Flags: blocking1.8.1?
Priority: -- → P2
Target Milestone: --- → mozilla1.8.1beta2
We should definitely fix this, but fwiw I'm pretty sure that I've seen the HTTP authentication request dialog pop up for extension updates (in fact, I remember being frustrated about it because it would do so when I started Firefox and block the rest of my UI).
Flags: blocking1.8.1? → blocking1.8.1+
I suspect that the authentication dialog wasn't shown due to extension update and was shown for some other reason... xpinstall has never had the code to do so afaict.
I believe the joga extension made it's own request for updates (seperate from the Firefox's built-in updates), so that probably explains what beltzner saw.
Too late to muck with xpinstall at this late stage, but we should look at getting this on trunk ASAP.
Flags: blocking1.8.1+ → blocking1.9a1?
*** Bug 346974 has been marked as a duplicate of this bug. ***
*** Bug 351751 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Flags: blocking1.8.1?

Comment 12

11 years ago
I've run into this three or four times lately and thought it was something I've done but in fact it turned out that the add-ons manager didn't prompt for proxy auth.

~B
If it was too late in July, its way too late six weeks later.
Flags: blocking1.8.1? → blocking1.8.1-
Flags: blocking1.9a1? → blocking1.9-
(Assignee)

Comment 14

11 years ago
*** Bug 359171 has been marked as a duplicate of this bug. ***
*** Bug 359749 has been marked as a duplicate of this bug. ***
*** Bug 359940 has been marked as a duplicate of this bug. ***
*** Bug 360074 has been marked as a duplicate of this bug. ***
*** Bug 360721 has been marked as a duplicate of this bug. ***

Comment 19

11 years ago
As described in bug #351751, the same problem occurs when you have extensions or themes installed and use a proxy connection which requires authentication. When you launch FF and it detects available extension or theme updates, the update window pops up, but when you click on the update button the download fails, because FF doesn't ask for the proxy authentication. 

If you first browse a URL and authenticate on the proxy, then try to update the same extensions or themes using the Tools->extensions menu, then it works, because you are already authenticated on the proxy server.
*** Bug 361034 has been marked as a duplicate of this bug. ***
*** Bug 361033 has been marked as a duplicate of this bug. ***

Comment 22

11 years ago
*** Bug 361263 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 23

11 years ago
*** Bug 364087 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

11 years ago
Duplicate of this bug: 365757
(Assignee)

Updated

10 years ago
Duplicate of this bug: 357262
Duplicate of this bug: 367014

Updated

10 years ago
Duplicate of this bug: 367877
This was minused for 1.9a1, which somehow turned into a 1.9 minus. Since that time FF2 shipped and we've collected a lot of dupes because of the issue described in comment 19. It's the same underlying issue as the original problem but a circumstance that's far more common than those considered when this was originally minused.
Flags: blocking1.9- → blocking1.9?
Summary: extension update installation does not try authentication if needed. → extension update does not try authentication if needed (e.g. proxy auth at startup)
Whiteboard: see comment 19
Duplicate of this bug: 369459
Duplicate of this bug: 369792
(Assignee)

Updated

10 years ago
Duplicate of this bug: 379688
(Assignee)

Updated

10 years ago
Duplicate of this bug: 380255
(Assignee)

Updated

10 years ago
Duplicate of this bug: 381908

Updated

10 years ago
Duplicate of this bug: 383104
(Assignee)

Comment 35

10 years ago
Created attachment 267567 [details] [diff] [review]
patch rev 1

Given the lack of progress here I'll take this. This is a patch that works in my testing and is basically taken from the xmlhttprequest code.
Assignee: darin.moz → dtownsend
Attachment #267567 - Flags: review?(dveditz)
Comment on attachment 267567 [details] [diff] [review]
patch rev 1

r/sr=dveditz

We probably want to make this better in FF2 also
Attachment #267567 - Flags: review?(dveditz)
Attachment #267567 - Flags: review+
Attachment #267567 - Flags: approval1.8.1.5?
(Assignee)

Comment 37

10 years ago
Checking in nsXPInstallManager.cpp;
/cvsroot/mozilla/xpinstall/src/nsXPInstallManager.cpp,v  <--  nsXPInstallManager.cpp
new revision: 1.148; previous revision: 1.147
done
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Comment on attachment 267567 [details] [diff] [review]
patch rev 1

approved for 1.8.1.5, a=juanb for release-drivers
Attachment #267567 - Flags: approval1.8.1.5? → approval1.8.1.5+
(Assignee)

Updated

10 years ago
Keywords: fixed1.8.1.5
Target Milestone: mozilla1.8.1beta2 → mozilla1.9alpha6

Comment 39

10 years ago
Christian:  Can you please help us verify this fix with the latest 1.8 (2.0.0.5pre) nightly?

If anyone else has a testcase or extension setup behind an http auth, please share.  Thanks!
Whiteboard: see comment 19 → see comment 19 [need testcase]
(Assignee)

Updated

10 years ago
Duplicate of this bug: 388134
(Assignee)

Comment 41

10 years ago
(In reply to comment #39)
> If anyone else has a testcase or extension setup behind an http auth, please
> share.  Thanks!

Jay I've just verified that this works for me in 2.0.0.6 with an extension update behind a proxy server requiring auth.
Whiteboard: see comment 19 [need testcase]

Comment 42

10 years ago
I'm behind a Squid-proxy server.
I can confirm that 2.0.0.6 works well, i receive an authentication request
and the update download is authorized.
The only problem is that this authorization request appear not to be forwarded.
I mean, as far as i open another web page, the auth request will pop up again.
After that i can continue browsing without receiving any other auth request.
In a nutshell, it works, but in the case that an authorization is requested
at startup for an update, it will be requested TWICE, this is unnecessary as
far the user already have authenticated itself on the first run.
Should we file another bug for this ?
(Assignee)

Comment 43

10 years ago
(In reply to comment #42)
> Should we file another bug for this ?

Yes please
Please cc me on the new bug... we've had a few discussions on the restart on startup requirement when installing extensions which causes this and we really need to fix that to fix this.

Updated

10 years ago
Blocks: 390760

Comment 45

9 years ago
Something screwed up in latest firefox update.
Proxy auth dialog popup unexpectly without caching the previously saved authentication data. The checkbox for saving data dont stuck checked.
(Assignee)

Updated

8 years ago
Flags: in-testsuite+
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.