Closed Bug 371242 Opened 17 years ago Closed 17 years ago

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

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: pascalc, Assigned: oremj)

Details

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?
(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.
Sherman - can you comment on what you'd like the desired behavior to be?
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.
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?

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).
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.
Sherman - what would you like done here?
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.
Assignee: server-ops → oremj
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?
sounds good to me
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
Closed: 17 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
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 → ---
Fixed for these locales.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 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.