Closed Bug 312473 Opened 16 years ago Closed 14 years ago

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

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P2)

1.8 Branch
x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9alpha6

People

(Reporter: christian.schaefer, Assigned: mossop)

References

Details

(Keywords: fixed1.8.1.5)

Attachments

(1 file)

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?
> 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
-> me
Assignee: xpi-engine → darin
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. ***
Flags: blocking1.8.1?
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-
*** 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. ***
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. ***
*** Bug 361263 has been marked as a duplicate of this bug. ***
*** Bug 364087 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 365757
Duplicate of this bug: 357262
Duplicate of this bug: 367014
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
Duplicate of this bug: 379688
Duplicate of this bug: 380255
Duplicate of this bug: 381908
Duplicate of this bug: 383104
Attached patch patch rev 1Splinter Review
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?
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
Closed: 14 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+
Keywords: fixed1.8.1.5
Target Milestone: mozilla1.8.1beta2 → mozilla1.9alpha6
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]
Duplicate of this bug: 388134
(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]
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 ?
(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.
Blocks: 390760
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.
Flags: in-testsuite+
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.