Re: Use of CryptoKey with polyfill

No, he's talking about algorithm specific aspects of support, not
generic support.

var promise = promise.reject(AnythingReally);
if (window.crypto.subtle) {
  promise = window.crypto.subtle.generateKey(...);
}
promise.then(
   (key) => { return { 'key': key, 'interface': window.crypto.subtle },
   (error) => { return yourPolyfill.generateKey(...).then(
     (yourKey) => { return { 'key': yourKey, 'interface': window.crypto.subtle }
   }).then((object) => {
      return object.YourThing(object.key, ...)
          .then(object.YourOtherThing(object.key, ...))
          .then(object.YourFinalThing(...));
    })
    .then((result) => { doSomething(result); });
}

This is just a hacky solution that polyfills in support at the Promise
level. In a 'production' grade code, you could create a Polyfill
object that handled all algorithms / operations and used tricks like
looking at whether key instanceof CryptoKey to know whether to defer
to the underlying implementation (or any other approach you wished)

To explain the above example a bit more thoroughly - if the promise to
generate the key was rejected (e.g. not supported), then the exception
handler *for that promise* calls to yourPolyfill. yourPolyfill returns
a promise to generate a key (which it may have done synchronously -
e.g. via Promise.resolve(someSynchronousEvent) ), and then the success
of that polyfill tells the rest of the promise chain to use your
polyfill for whatever other things you need, rather than going to
window.crypto.subtle.

The first promise is either immediately resolved (the (key) => {...})
when WebCrypto generates the key, or it can be a continuation (by
virtue of returning a promise).

Hopefully that handwavy bit made sense.

On Mon, Jan 12, 2015 at 2:55 PM, Richard Barnes <rlb@ipv.sx> wrote:
> W.r.t. 2: "if (window.crypto.subtle) { ... }", right?
>
> On Mon, Jan 12, 2015 at 10:37 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>>
>> This may be an issue of ignorance on my part, if it is please excuse me.
>>
>>
>>
>> I am currently writing some code and have found that one or more of the
>> algorithms that I need for it are not either on the currently supported or
>> planned supported list for the browser that I am using.  The way that I
>> would normally solve this is by doing polyfill for the missing algorithms.
>> In looking at this I have run into a couple of issues that I am not sure how
>> to deal with.
>>
>>
>>
>> 1.       Is it possible to create a script size class which has the
>> CryptoKey interface in the prototype chain?  This is one of two issues that
>> I have (so far) discovered with the use of “instanceof CryptoKey” as a
>> discriminator in writing my library code.  (The second is the fact that
>> interfaces which are remoted from a different environment will have this be
>> false.)  I have not actually tried to write the correct polyfill for this
>> but have not yet found anything that would support it working either.  My
>> first guess is that this might be very dependent on how the browser
>> implements interfaces.
>>
>> 2.       If I want the polyfill to be conditional, then the normal
>> approach I have seen in the past is to do some type of test on the feature
>> and either define or not define the polyfill as appropriate.   I am not sure
>> how this is going to work out with a Promises approach to everything.
>> Currently the way that I would think about this is to generate a key with
>> the algorithm in question.  However given that the result the promise would
>> be pending unless the algorithm is not in the dictionary to be normalized.
>> I am also not sure when the promises would be scheduled relative to the
>> onload event – would they complete before the onload or would they be
>> potentially afterwords.  My assumption is that the timing is totally
>> arbitrary.  This means that the polyfill code may need to be called and
>> started prior to it finding out if the feature it is filling in for actually
>> exists in the base implementation.
>>
>>
>>
>> Help – Jim
>>
>>
>
>

Received on Monday, 12 January 2015 23:16:56 UTC