Граф коммитов

3 Коммитов

Автор SHA1 Сообщение Дата
Boris Zbarsky e379022658 Bug 1551282 and bug 1553436. Allow pages to override window.u2f but not the "sign" and "register" properties on the U2F object. r=jcj,smaug
There are two related problems this patch is trying to address.  The first, and
simpler, one is bug 1553436: there are websites that use existing variables and
functions named "u2f" and adding a non-replaceable readonly property with that
name on Window breaks them.  The fix for this is straightforward: mark the
property [Replaceable].

The second problem, covered by bug 1551282, involves sites that use the Google
U2F polyfill.  The relevant parts of that polyfill look like this:

  'use strict';
  var u2f = u2f || {};
  u2f.register = some_function_that_only_works_right_in_Chrome;
  u2f.sign = some_function_that_only_works_right_in_Chrome;

The failure mode for that code before this fix is that the assignment to "u2f"
throws because it's a readonly property and we're in strict mode, so any code
the page concatenates in the same file after the polyfill does not get run.
That's what bug 1551282 is about.  The [Replaceable] annotation fixes that
issue, because now the polyfill gets the value of window.u2f and then redefines
the property (via the [Replaceable] setter) to be a value property with that
value.  So far, so good.

But then we need to prevent the sets of u2f.register
and u2f.sign from taking effect, because if they are allowed to happen, the
actual sign/register functionality on the page will not work in Firefox.  We
can't just make the properties readonly, because then the sets will throw due
to being in strict mode, and we still have bug 1551282.  The proposed fix is to
make these accessor properties with a no-op setter, which is exactly what
[LenientSetter] gives us.

The rest of the patch is just setting up infrastructure for generating the
normal bits we would generate if "sign" and "register" were methods and using
that to create the JSFunctions at the point when the getter is called.  The
JSFunctions then get cached on the u2f instance object.

Differential Revision: https://phabricator.services.mozilla.com/D32357

--HG--
extra : moz-landing-system : lando
2019-05-24 20:40:59 +00:00
shindli 54646b5a7c Backed out changeset 823ab2e5430a (bug 1551282) for Windows build bustages CLOSED TREE 2019-05-24 21:15:20 +03:00
Boris Zbarsky cd062bb5d7 Bug 1551282 and bug 1553436. Allow pages to override window.u2f but not the "sign" and "register" properties on the U2F object. r=jcj,smaug
There are two related problems this patch is trying to address.  The first, and
simpler, one is bug 1553436: there are websites that use existing variables and
functions named "u2f" and adding a non-replaceable readonly property with that
name on Window breaks them.  The fix for this is straightforward: mark the
property [Replaceable].

The second problem, covered by bug 1551282, involves sites that use the Google
U2F polyfill.  The relevant parts of that polyfill look like this:

  'use strict';
  var u2f = u2f || {};
  u2f.register = some_function_that_only_works_right_in_Chrome;
  u2f.sign = some_function_that_only_works_right_in_Chrome;

The failure mode for that code before this fix is that the assignment to "u2f"
throws because it's a readonly property and we're in strict mode, so any code
the page concatenates in the same file after the polyfill does not get run.
That's what bug 1551282 is about.  The [Replaceable] annotation fixes that
issue, because now the polyfill gets the value of window.u2f and then redefines
the property (via the [Replaceable] setter) to be a value property with that
value.  So far, so good.

But then we need to prevent the sets of u2f.register
and u2f.sign from taking effect, because if they are allowed to happen, the
actual sign/register functionality on the page will not work in Firefox.  We
can't just make the properties readonly, because then the sets will throw due
to being in strict mode, and we still have bug 1551282.  The proposed fix is to
make these accessor properties with a no-op setter, which is exactly what
[LenientSetter] gives us.

The rest of the patch is just setting up infrastructure for generating the
normal bits we would generate if "sign" and "register" were methods and using
that to create the JSFunctions at the point when the getter is called.  The
JSFunctions then get cached on the u2f instance object.

Differential Revision: https://phabricator.services.mozilla.com/D32357

--HG--
extra : moz-landing-system : lando
2019-05-24 17:19:23 +00:00