When reporting a Phishing site the 'Report Sent' page is in English instead of showing the localized version of the page

RESOLVED FIXED

Status

RESOLVED FIXED
12 years ago
4 years ago

People

(Reporter: pascalc, Assigned: oremj)

Tracking

Details

(Reporter)

Description

12 years ago
1 go to help/report a phishing site on a localized version of Firefox (tested with FR and es-ES versions)
2 report a web site and submit report

Actual result:
You are directed to this English page :
http://www.google.com/tools/firefox/toolbar/FT2/intl/en/submit_success.html

Expected result:
You should be directed to a localized version of the page:
http://www.google.com/tools/firefox/toolbar/FT2/intl/fr/submit_success.html
http://www.google.com/tools/firefox/toolbar/FT2/intl/es/submit_success.html

According to my http sniffer, the redirection path is the following :

http://fr.phish-report.mozilla.com/?hl=fr
-> Location: http://www.google.com/safebrowsing/report_phish/?tpl=mozilla&continue=http%3A%2F%2Fwww.google.com%2Ftools%2Ffirefox%2Ftoolbar%2FFT2%2Fintl%2Fen%2Fsubmit_success.html&hl=fr&url=

The right redirect should be :
Location: http://www.google.com/safebrowsing/report_phish/?tpl=mozilla&continue=http%3A%2F%2Fwww.google.com%2Ftools%2Ffirefox%2Ftoolbar%2FFT2%2Fintl%2Ffr%2Fsubmit_success.html&hl=fr&url=

the &continue parameter is not picking up the locale parameter initially sent to mozilla.com, which makes it a mozilla.com server-side bug I think (CCing wclouser about it)
That sounds like a reasonable assumption, but I don't know where the code for phish-report.m.c is, and reed suggests it's hosted by google (and cites bug 348878).

Adding reed and oremj to the CC list to get input.  Once we figure out where the code is hosted, we can move this out of phishing.protection@firefox.bugs
Assignee: nobody → server-ops
Component: Phishing Protection → Server Operations
OS: Windows XP → All
Product: Firefox → mozilla.org
QA Contact: phishing.protection → justin
Hardware: PC → All
Version: unspecified → other
Basically, the redirect just needs to use the passed locale for the directory in the continue link. However, Google doesn't use ab-CD but ab for a lot of its stuff, so we probably need to strip the "-CD" part from the locale.

Tony: Are there any cases where ab-CD is used over ab in the continue URL for locales?

Comment 3

12 years ago
(In reply to comment #2)
> Basically, the redirect just needs to use the passed locale for the directory
> in the continue link. However, Google doesn't use ab-CD but ab for a lot of its
> stuff, so we probably need to strip the "-CD" part from the locale.
> 
> Tony: Are there any cases where ab-CD is used over ab in the continue URL for
> locales?

If you switch the FT2 directory to FT3, the list of locales we support are:
ar, bg, cs, da, de, el, en, en-GB, es, fi, fr, hu, it, iw, ja, ko, nl, no, pl, pt-BR, ru, sk, sv, tr, zh-CN and zh-TW.

Unfortunately, for legacy reason, some of these are not the current language codes (iw instead of he and no instead of nb).

It would be nice if there was some sort of automatic fallback if a locale didn't exist...
So where is this code hosted?
The code is hosted all by Google. We just redirect to it through some mod_rewrite magic.
... and it's the rewrite that needs to be fixed.

Comment 7

12 years ago
Sherman - can you comment on what you'd like the desired behavior to be?

Comment 8

12 years ago
It seems to me that redirects need to be handled by Google once we pass the URL off to them, but I would be curious to know if there is anything we could do in the product to address the issue.  I suspect not.  

Desired behavior would be for the submit response to be presented in the same locale as the submit form.  If the locale doesn't exist, it should default to en-US.

Comment 9

12 years ago
Tony,
Just wanted to explore one option... 
If we correctly pass the locale to the submit page, couldn't we capture that with  some .js, and then pass the variable into the hidden continue field?
(Reporter)

Comment 10

12 years ago
I think the google page is a dynamically generated page using the variables from the url to generate the html so I guess that if they have to touch this page it makes more sense to fix their page generation than to add javascript (plus it wouldn't work in browser with javascript disabled).

Comment 11

12 years ago
The reason for the continue= url parameter is so that you can use the same submit page with different success pages (e.g., Google toolbar users vs Firefox 2.0 users).  However, we're currently redirecting everyone to the same place.

We may be able to add some server logic to do something smarter if the continue URL isn't provided (currently just goes to the English success page).  However, this would still require a mod_rewrite change on Mozilla's servers (dropping the continue param).  If we're going to have to do that anyway, can't we just fix the mod_rewrite rules to the list I provided above?

Anyway, I can do either, let me know.

Comment 12

12 years ago
Sherman - what would you like done here?

Comment 13

12 years ago
Ok, I suggest we make a mod_rewrite change to correctly pass the locale parameters into the redirection URL.  

Justin, please let me know if you see any issues or have any concerns.

Updated

12 years ago
Assignee: server-ops → oremj
(Assignee)

Comment 14

12 years ago
My strategy here will be to redirect using the correct locale if it is in:
ar, bg, cs, da, de, el, en, en-GB, es, fi, fr, hu, it, iw, ja, ko, nl, no, pl,
pt-BR, ru, sk, sv, tr, zh-CN and zh-TW.

Else I will redirect to en.

Does that sound good to everyone?
(Reporter)

Comment 15

12 years ago
sounds good to me
(Assignee)

Comment 16

12 years ago
Added a rewrite rule to catch locales that google is aware of.  Seems to work.

     RewriteEngine On
+    RewriteCond %{QUERY_STRING} ^hl=(ar|bg|cs|da|de|el|en|en-GB|es|fi|fr|hu|it|iw|ja|ko|nl|no|pl|pt-BR|ru|sk|sv|tr|zh-CN|zh-TW)&url=(.+)
+    RewriteRule ^/$ http://www.google.com/safebrowsing/report_phish/?tpl=mozilla&continue=http\%3A\%2F\%2Fwww.google.com\%2Ftools\%2Ffirefox\%2Ftoolbar\%2FFT2\%2Fintl\%2F%1\%2Fsubmit_success.html&hl=%1&url=%2 [R,NE]
     RewriteCond %{QUERY_STRING} ^hl=(.*)&url=(.+)
     RewriteRule ^/$ http://www.google.com/safebrowsing/report_phish/?tpl=mozilla&continue=http\%3A\%2F\%2Fwww.google.com\%2Ftools\%2Ffirefox\%2Ftoolbar\%2FFT2\%2Fintl\%2Fen\%2Fsubmit_success.html&hl=%1&url=%2 [R,NE]
     RewriteRule ^/.*$ http://www.mozilla.com/ [R]
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
es-ES it is not including
In Firefox "Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2" the result follows bad
http://www.google.com/tools/firefox/toolbar/FT2/intl/en/submit_success.html
(Reporter)

Comment 19

12 years ago
Fernando is right, we use in Firefox long locale names that need to be converted to the locale names used by google:

es-ES -> es
es-AR -> es
nb-NO -> no
nn-NO -> no
pt-PT -> pt-BR
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 20

12 years ago
Fixed for these locales.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
Jeremy I see that already it works correctly, thanks 
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.