VersionCheck.php doesn't work if the user's UserAgent is screwed up by an extension

RESOLVED WONTFIX

Status

mozilla.org Graveyard
Server Operations
--
critical
RESOLVED WONTFIX
13 years ago
3 years ago

People

(Reporter: hunk4004, Unassigned)

Tracking

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.8) Gecko/20050511 Firefox/1.0.1 StumbleUpon/1.9992
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.8) Gecko/20050511 Firefox/1.0.1 StumbleUpon/1.9992

I've updated to firefox 1.04 and when i try to go to the extensions, addons ecc.
it tells me that i must update?!?

Reproducible: Always

Steps to Reproduce:
1.Just click on extensions
2.
3.

Actual Results:  
It told me to update to firefox 1.04(which i have done so)

Expected Results:  
it shouldn't of asked me to update since i did already thus making it
impossibile to download any extensions ecc.

Comment 1

13 years ago
The reason for the fact it is telling to to continue to update is because you
use, or have used, the StumbleUpon extension.

Unfortunately, I'm not sure of the instructions for changing this, though.
Assignee: general → Bugzilla-alanjstrBugs
Component: Bugzilla-General → Web Site
Product: Bugzilla → Update
QA Contact: default-qa → mozilla.update

Comment 2

13 years ago
Go to about:config
search for useragent
look for the vendorSub
If it does not say 1.0.4, right click it and choose reset,

Comment 3

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

Updated

13 years ago
Summary: cannot access the addons with FF 104 because it continues to tell me tu update → Tells me to update when I have FX 1.0.4
Whiteboard: Please read comment number 2 and post if you still have a problem

Comment 4

13 years ago
Users need to be more aware of why they're being redirected to the upgrade page.
 It would be helpful if the user's UA is displayed since that's what we're
filtering on.  Also, since Stumbleupon causes the UA to be wrong, it would be
helpful if we detected if it is installed and suggest the resetting of the
vendorSub (or provide a mechanism to do so).
Assignee: Bugzilla-alanjstrBugs → mozilla.webmaster
Severity: major → normal
Status: UNCONFIRMED → NEW
Component: Web Site → webmaster@mozilla.org
Ever confirmed: true
OS: Windows XP → All
Product: Update → mozilla.org
QA Contact: mozilla.update → danielwang
Hardware: PC → All
Whiteboard: Please read comment number 2 and post if you still have a problem
Version: unspecified → other

Comment 5

13 years ago
*** Bug 294781 has been marked as a duplicate of this bug. ***
Created attachment 184082 [details] [diff] [review]
JS test with instructions

This adds a javascript test for a UserAgent string with a space after the
Firefox version number.  If this is detected, it unhides an initially-hidden
<div> with instructions to tell the user how to fix it.  The wording of the
instructions needs marketing review.
Assignee: mozilla.webmaster → justdave
Status: NEW → ASSIGNED
Attachment #184082 - Flags: review?(rebron)
Note this is a fairly high priority to get landed...  webmaster and the press
contacts have been getting lots of email from people getting bit by this.
Severity: normal → critical
Priority: -- → P1

Comment 8

13 years ago
You'll also need to detect Ubuntu

Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.7.6) Gecko/20050512 Firefox/1.0
(Ubuntu package 1.0.2)

Comment 9

13 years ago
*** Bug 294998 has been marked as a duplicate of this bug. ***
(In reply to comment #8)
> You'll also need to detect Ubuntu
> 
> Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.7.6) Gecko/20050512 Firefox/1.0
> (Ubuntu package 1.0.2)

It already does.  All I'm doing is looking for a space after the Firefox version
number, which Ubuntu's UA has.  On the other hand, the fix we suggest isn't
going to work for Ubuntu since they've actually got 1.0.2 with backports (and
why does their UA say 1.0 on the actual Firefox listing?) so resetting their
vendorSub is going to make it 1.0.2 which still won't get them in.  Guess I need
to do a separate detection for Ubuntu and point them at
https://bugzilla.ubuntu.com/show_bug.cgi?id=10681 instead.

As for setting the rewrite on Addons to let the new fixed Ubuntu package in, I'm
not sure I can reliably detect on "Ubuntu package 1.0.2".  They didn't change
the UA when they applied the security patches, so I've got no way to detect the
user has a fixed version.

cbeard/chofmann: can I get signoff from someone on the text of the "workaround
instructions" in the existing patch on this bug?  It might need a little
massaging yet from a marketing person to avoid confusing people.  I'll have a
new patch up soon that does an alternate message for people with Ubuntu to point
them at the bug on Ubuntu's bug system.
Created attachment 184206 [details] [diff] [review]
Add special-case for Ubuntu

I'm going to go ahead and run with this, since we're still periodically getting
folks in IRC complaining about it.  The marketing folks can fix it Monday if
they don't like it. :)
Attachment #184082 - Attachment is obsolete: true
Checking in html/products/firefox/upgrade/index.html;
/cvsroot/mozilla-org/html/products/firefox/upgrade/index.html,v  <--  index.html
new revision: 1.5; previous revision: 1.4
done
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 13

13 years ago
This bug also has another aspect, so you might need to consider reopening.  The
other problem is that if an extension can alter the vendorSub string, it can
also prevent Fx from updating extensions.  If an extension requires a more
recent version, then the extension cannot be updated.  There are examples of
this in the Support Forum, also due to StumbleUpon.  If pressed hard enough I
suppose I could find one.

Comment 14

13 years ago
VersionCheck and the ExtensionManager do not use vendorSub.  They use
app.extensions.version
(In reply to comment #14)
> VersionCheck and the ExtensionManager do not use vendorSub.  They use
> app.extensions.version

Except that you can't even get to VersionCheck if your UserAgent is fubared.

We can't get around that without exposing the security hole again if we were to
allow that URL through (any URL on that domain actually delivering content to an
old version is a security risk).  We probably *can* specifically redirect that
URL to some other domain, and make the VersionCheck script available via that
domain.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
QA Contact: danielwang → polvi
Summary: Tells me to update when I have FX 1.0.4 → VersionCheck.php doesn't work if the user's UserAgent is screwed up by an extension
Status: REOPENED → NEW
Component: webmaster@mozilla.org → Server Operations
This is a mass-reassign of bugs that I'm not actively working on right at this moment to the default component owner, since we now have a larger IT staff than just me.  These bugs will be getting redistributed to other sysadmins as sysadmin time becomes available.
Assignee: justdave → server-ops
Priority: P1 → --
QA Contact: polvi → myk
Justin is now the QA for this component.
QA Contact: myk → justin
Not sure if we still care on this...  what's product management think?  cbeard?
Assignee: server-ops → nobody
Component: Server Operations → Server Operations Projects

Comment 19

12 years ago
This looks like a addons problem not a server operation problem.
Component: Server Operations Projects → Add-ons
Product: mozilla.org → addons.mozilla.org
Version: other → 2.0

Updated

12 years ago
QA Contact: justin → morgamic
The UA sniffing is done at a much higher level than the app level.  Could we  make the condition less greedy (only look for the version, maybe, instead of searching for a verbatim UA string)?

Either way, AMO is on the app level, so I'd say this is still an IT problem since developers don't have access to the mechanism that is causing the redirections to happen.
Assignee: nobody → server-ops
Component: Add-ons → Server Operations
Product: addons.mozilla.org → mozilla.org
Version: 2.0 → other
So, if package maintainers can't maintain the client version in the UA string properly, there's not a whole lot we can do, then... :(

Doesn't it make sense that a package for Firefox 1.5.0.6 would have 1.5.0.6 _somewhere_ in the UA string?
The extension authors who were screwing it up seem to have learned from it, and the extension developer docs explicitly warn against screwing with it now.

What's outlined in comment 15 is probably the only possible way to deal with it, but this is ancient enough, I'm not sure it's worth fixing anymore.

Comment 23

12 years ago
No action on this for a long time, please reopen if someone is still having problems.
Status: NEW → RESOLVED
Last Resolved: 13 years ago12 years ago
Resolution: --- → WONTFIX
WFM! :)
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.