505031 - Plugins blocklist page can not be opened from addons manager in localized Firefox builds

Status: VERIFIED FIXED

(www.mozilla.org :: General, defect, P2)

Description

[Alexander L. Slovesnik]

Attachment: Screenshot

STR:
1. Install Firefox 3.5.1 Russian build for Win32
2. Install some plugin that is blacklisted in Firefox (Quicktime 7.1.3 in my case)
3. Open Tools -> Addons -> Plugins
4. Highlight blocked plugin and click link "More information"

Expected results: Firefox shows https://www.mozilla.com/en-US/blocklist/ page

Actual results: SSL error dialog is shown with text like "ru.www.mozilla.com uses an invalid security certificate. The certificate is only valid for *.mozilla.com" (see screenshot attached)

This error doesn't present in Fx 3.5.1 en-US build. This error doesn't present in Fx 3.0.11 Russian build

Comment 1

[Dave Townsend [:mossop]]

This is some problem with the redirecting at mozilla.com.
https://www.mozilla.com/ru/blocklist/ is the page the add-ons manager loads
which redirects to https://ru.www.mozilla.com/ru/blocklist/ which the
certificate doesn't match.

Comment 2

[Reed Loden [:reed]]

Bug 454299 would fix this.

Comment 3

[James May [:fowl2]]

With the recent WPF plugin blocklisting this is going to hit a whole lot more people.

The current behaviour is very malware-y:

1. dialog pops up with scary text
2. more info goes to a security warning page

(incidentally, once u ignore the warning, the page is completely useless and doesn't even include the WPF plugin)

Comment 4

[Dave Townsend [:mossop]]

We should block on this

Comment 7

[matthew zeier [:mrz]]

This is also tracked in bug 522864.

Comment 11

[Robert Kaiser]

Reed, the fun is that https://ru.www.mozilla.com/ru/blocklist/ with a cert exception (or a vaild cert) only redirects again to https://www.mozilla.com/en-US/blocklist/ so we redirect the URL without the locale subdomain the the one with the obsolete locale subdomain to redirect to the en-US page without the locale subdomain.

The fix could be "as simple as" changing the redirect for https://www.mozilla.com/*/blocklist/ to go to https://www.mozilla.com/en-US/blocklist/ directly, without redirecting to the obsolete locale subdomain in between.

Of course, I don't know the mechanisms behind this where the redirects are set, but saving a useless redirect level and at the same time fixing an instance of bug 454299 and not running into the cert problem would be worth any work on this, I guess :)

Comment 12

[Reed Loden [:reed]]

(In reply to comment #11)
Bug 454299 should fix all that.

My testing with the patch makes things go like this:
1. https://de.www.mozilla.com/de/blocklist/ -->
2. https://www.mozilla.com/de/blocklist/ -->
3. https://www.mozilla.com/en-US/blocklist/

We _may_ eventually be able to combine #1 and #2 together, but that would require some heavy dark magic.

Comment 13

[Axel Hecht [:Pike]]

As the code doesn't link to the sub-domains at all, the first redirect isn't really crucial, at least not for any current 3.5.x or later. The 2.->3. is the redirect that's golden our lives.

Comment 14

[Robert Kaiser]

Good, people should only come in with e.g. https://www.mozilla.com/de/blocklist/ so if that redirects in one single step and without going to the locale subdomain in between, we're where we want to be. :)

Comment 17

[Samuel Sidler (old account; do not CC)]

Okay, it's nice to know that bug 454299 will fix this issue, but that seems like a bigger fix. Why can't we just stop redirecting people to the locale subdomains right now? The in-product patches link to pages like this:

  http://www.mozilla.com/en-GB/blocklist/

Seems like we could just show that page...

Wil, we're planning on adding a new blocklist that at about 7% of Firefox users have. They will all run into this page. It'd be nice if, tomorrow when the blocklist hopefully gets updated, they don't see the cert error.

Comment 18

[Samuel Sidler (old account; do not CC)]

(In reply to comment #17)
>   http://www.mozilla.com/en-GB/blocklist/

This URL should be https.

https://www.mozilla.com/en-GB/blocklist/

Comment 19

[Wil Clouser [:clouserw]]

Attachment: fix?

Any change we do is going to need massive QA, whether it's this bug or the other one - they are both changing the same code.  Anyway, here is a patch that removes the redirect.

I can't reproduce all the redirects and stuff with SSL in my dev environment.  Stuff like https://de.www.mozilla.com/de/mobile/ works fine in production but ends up being a 404 for me, with or without this patch, so it's hard to say if this will work right.  Seems to work on www-trunk, maybe we should try this there.

Comment 20

[Reed Loden [:reed]]

Comment on attachment 409220 [details] [diff] [review]
fix?

I also don't have an SSL/non-SSL testbed, so I'll still need to check this on stage.

My tests:
* http://de.www.example.com/de/firefox/central/
-- no redirect; content displayed
* http://de.www.example.com/de/blocklist/
-- 302 redirect to http://www.example.com/en-US/blocklist/
* http://de.www.example.com/blocklist/
-- 301 redirect to http://de.www.example.com/de/blocklist/
* http://www.example.com/de/blocklist/
-- 302 redirect to http://www.example.com/en-US/blocklist/
* http://www.example.com/blocklist/
-- 302 redirect to http://www.example.com/en-US/blocklist/
* http://en-US.www.example.com/en-US/blocklist/
-- no redirect; content displayed
* http://www.example.com/en-US/blocklist/
-- no redirect; content displayed

All PASS. r=reed

Comment 21

[Reed Loden [:reed]]

(In reply to comment #20)
Oops, I forgot one more test:

* http://www.example.com/de/firefox/central/
-- no redirect; content displayed

Still PASS.

Comment 22

[Wil Clouser [:clouserw]]

on stage in r54633.  QA:  Please check www-trunk after it updates.

Comment 23

[Stephen Donner [:stephend] Not actively reading bugmail]

I don't have a whole lot of free time tonight to test this, but here's a start (all of these appear to be correct thus far):

[1] /firefox: http://de.www-trunk.stage.mozilla.com/de/firefox/ redirects to http://www.mozilla-europe.org/de/firefox/
[2] /whatsnew: https://sv-se.www-trunk.stage.mozilla.com/firefox/3.5.3/whatsnew redirects to https://www-trunk.stage.mozilla.com/sv-SE/firefox/3.5.3/whatsnew/
[3] /first run: https://www-trunk.stage.mozilla.com/firefox/3.5.3/firstrun/ redirects to https://www-trunk.stage.mozilla.com/en-US/firefox/3.5.3/firstrun/
[4] /central: https://www-trunk.stage.mozilla.com/de/firefox/central/ and http://de.www-trunk.stage.mozilla.com/de/firefox/central/ redirect to https://www-trunk.stage.mozilla.com/de/firefox/central/

That's just simple regression testing; would love it if someone could pick the top 5 locales, plus en-US, and test /blocklist, both with and without the locale-subdomain prefix and the /locale/ code too.

More tomorrow morning.

Comment 24

[Vishal Kamdar [:vish_moz]]

I did some locale testing:
zh-CN:
    zh-CN.www-trunk.stage.mozilla.com/zh-CN/blocklist - PASS

    www-trunk.stage.mozilla.com/zh-CN/blocklist - PASS

en-GB:
     https://en-gb.www-trunk.stage.mozilla.com/en-GB/blocklist  -> gives        Untrusted Connection ->after accepting the certificate redirects to -> https://www-trunk.stage.mozilla.com/en-US/blocklist/

   https://www-trunk.stage.mozilla.com/en-GB/blocklist - PASS

fr:
   https://fr.www-trunk.stage.mozilla.com/fr/blocklist -> gives Untrusted  Connection ->after accepting the certificate redirects to -> https://www-trunk.stage.mozilla.com/en-US/blocklist/

  https://www-trunk.stage.mozilla.com/fr/blocklist - PASS

he:
  https://he.www-trunk.stage.mozilla.com/he/blocklist -> gives Untrusted Connection ->after accepting the certificate redirects to -> https://www-trunk.stage.mozilla.com/en-US/blocklist/

  https://www-trunk.stage.mozilla.com/he/blocklist - PASS

es-ES
     https://es-es.www-trunk.stage.mozilla.com/es-ES/blocklist -> gives Untrusted Connection ->after accepting the certificate redirects to ->   https://www-trunk.stage.mozilla.com/en-US/blocklist/

    https://www-trunk.stage.mozilla.com/es-ES/blocklist - PASS

Comment 25

[Wil Clouser [:clouserw]]

They all look fine to me.  Is this a=qa?

Comment 26

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #25)
> They all look fine to me.  Is this a=qa?

Let's do it; feeling a lot more confident about this since our testing (although it still makes me slightly nervous, given the magnitude).

Comment 27

[John Slater]

(In reply to comment #26)
> (In reply to comment #25)
> > They all look fine to me.  Is this a=qa?
> 
> Let's do it; feeling a lot more confident about this since our testing
> (although it still makes me slightly nervous, given the magnitude).

If QA is on board, then it works for me. Let's do it...

Comment 28

[Wil Clouser [:clouserw]]

Thanks everyone, this is on stage and production in r54670.

Comment 29

[Samuel Sidler (old account; do not CC)]

I see it's live and working. :)

Big thanks to everyone that made this happen so fast. Great work! :)

Comment 30

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED; any fallout goes to a new bug :-)