Summary: XPI installations should work on XPI location instead of the website → Allowed domains for xpi installations should work on doman of the xpi instead of the website
Because of the unknown severity just asking for blocker of PR1 to avoid an unnecessary patch release.
Same behavior applies for update.mozilla.org. I'm not able to install any extensions! Updating the URL.
Ok, I checked the behaviour more deeply and noticed that installation fails when we dont send a referer. When the the preference 'network.http.sendRefererHeader' is disabled you will stay in a loop for editing the white list of allowed websites. I updated the status for this bug cause it doesn't seems to be critical.
Severity: critical → normal
Summary: Allowed domains for xpi installations should work on doman of the xpi instead of the website → Online installation of extensions fails when pref 'network.http.sendRefererHeader' is set to false
(In reply to comment #3) > Ok, I checked the behaviour more deeply and noticed that installation fails when > we dont send a referer. When the the preference 'network.http.sendRefererHeader' > is disabled you will stay in a loop for editing the white list of allowed websites. Note that programs like Norton Internet Security also block the sending of a referrer as part of their privacy protection.
I didn't know the internal process but do we really need a referrer? All processing should be done locally. We have our white list of domains and know the location within the current window or frame. Why not check this instead of using a referrer?
This hampers a lot of people who have disabled referrers. Asking for blocker of aviary1.0.
I checked that the referrer pref isn't a bool pref. Every installation fails when the pref hasn't a value of two.
Summary: Online installation of extensions fails when pref 'network.http.sendRefererHeader' is set to false → Online installation of extensions fails when pref 'network.http.sendRefererHeader' has not the value 2
dveditz introduced referrer-checking for XPIs in bug 240552 (see bug 240552 comment 38). It might be nice to have a separate "internal referrer" field that could work with FTP, wouldn't get disabled or spoofed, etc.
Not sure we must fix this for 1.0, I'll let others + this bug. /be
The channel owner could have been such an "internal referrer" mechanism, but trying to use it that way really messed things up when I tried it. Later jst rediscovered that same thing when trying something similar while fixing the frame-spoofing bug. nsIChannel2?
Is this going to cause problems if we force everyone to use HTTPS for update.mozilla.org? (Links from HTTPS doesn't get a referer, although IMO they should get the hostname without a path as a referer.)
*** Bug 259743 has been marked as a duplicate of this bug. ***
15 years ago
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Browser
Version: unspecified → Trunk
not a common case. I don't think we block on this.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Assignee: bugs → xpi-engine
QA Contact: bugs
You need to log in before you can comment on or make changes to this bug.