Closed Bug 653307 Opened 11 years ago Closed 11 years ago

Adjust reCAPTCHA NoScript hack in Sync


(Firefox :: Sync, defect)

Not set



Tracking Status
firefox5 --- fixed


(Reporter: rnewman, Assigned: rnewman)



(Whiteboard: [verified in services])


(4 files)

Sync currently adds to the NoScript whitelist during setup. That URL is no longer valid (they're using now), and NoScript has appropriate entries in its own whitelist.

Furthermore, we already have a fallback for disabled JS, so our workaround code is unnecessary. KILL THE HEATHEN CODE!
Assignee: nobody → rnewman
Summary: Remove redundant NoScript hack from Sync → Remove redundant reCAPTCHA NoScript hack from Sync
Attached image Screenshot.
Let's just say that the user experience with NoScript is less than ideal.
Attached image With exception added.
Taking a look at this scrollbar annoyance.
Summary: Remove redundant reCAPTCHA NoScript hack from Sync → Adjust reCAPTCHA NoScript hack in Sync
Attached image The best I can do...
Have to force a minwidth of 700 on the wizard as whole. Let's hope this looks OK on Windows and Linux…
This temporarily adds to the whitelist.
Attachment #528945 - Flags: review?(philipp)

* New profile.
* Install NoScript:
* Restart as required.
* Set up Sync. Captcha page in the wizard should look like Attachment 528915 [details], not Attachment 528899 [details].
Comment on attachment 528945 [details] [diff] [review]
Alter URL for whitelist. v1

>+// Broader than we'd like, but after this changed from
>+// we had no choice. At least we only do this for the duration of setup.
>+const RECAPTCHA_DOMAIN = "";

This makes me sad, but apparently NoScript does indeed not allow us to restrict it further as Giorgio writes in bug 508112 comment 14:

  Yes it does. A "site" for NoScript must be either a prePath (in nsIURI terms)
  or a host.

>-  _remoteSites: [Weave.Service.serverURL, ""],
>+  _remoteSites: [Weave.Service.serverURL, RECAPTCHA_DOMAIN],

Interesting (pre-existing) bug here: We will always whitelist only auth.s.m.c. If the user changes 'serverURL' by typing in a custom server URL and that custom server also requires a captcha (the minimal server doesn't, but conceivably others could), we never whitelist it. Fix would be to make this a dynamic getter always:

  get _remoteSites(): [Weave.Service.serverURL, RECAPTCHA_DOMAIN],

r=me with that. Please request approval for aurora and 2.0 for the updated patch.
Attachment #528945 - Flags: review?(philipp) → review+
Pushed to services:
Whiteboard: [fixed in services]
Comment on attachment 528945 [details] [diff] [review]
Alter URL for whitelist. v1

Requesting approval for Aurora and 4.0.2 for this patch:

Justification: without this updated URL, NoScript users will have a degraded Sync signup experience, as shown in Attachment 528899 [details].
Attachment #528945 - Flags: approval2.0?
Attachment #528945 - Flags: approval-mozilla-aurora?
Verified with s-c builds of 20110502 and NoScript installed
Whiteboard: [fixed in services] → [verified in services]
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
Attachment #528945 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Pushed to Aurora:
Target Milestone: mozilla6 → mozilla5
Comment on attachment 528945 [details] [diff] [review]
Alter URL for whitelist. v1

Not planning any more 2.0 releases, no point in landing this there.
Attachment #528945 - Flags: approval2.0? → approval2.0-
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.