l15k4 / scalajs-rx-idb Goto Github PK

Any class that extends js.Any can be serialised to IndexDB, as pointed out by @sjrd on the scalajs mailing list Structured Cloning thread.

upickle is quite inefficient regarding structured cloning at present, and is problematic for serialising special objects like opaque objects produced by WebCrypto: see issue 127 of upickle and issue #3 in this rep. It seems unlikely that upickle will be changed soon to change that, as it would require quite a lot of rewrite of the macro library, which is not easy to do.

One answer is to only allow JS classes to be serialised to disk, that is classes that extend js.Any. That would reduce the dependence on upickle, and make the code a lot simpler. For a programmer that may mean building special classes for serialisation or writing a mapper to map scala classes (ie. ones that do not extend js.Any) The programmer could then choose what library to use: upickle being in many cases a very good choice.

Hi I need to use IndexDB to save a CryptoKeyPair which I am in the process of submitting a patch to org.scalajs.dom for.

Before I spend a lot of time setting everything up, I wanted to make sure I could save a pure JS object using scalajs-rx-idb. Reading your README I can't tell if you only save case classes. This is a particular object because if you make it setting extractable to false in the generateKey method as here:

GlobalCrypto.crypto.subtle.generateKey(
       RsaHashedKeyGenParams("RSASSA-PKCS1-v1_5",
         2048,
         new BigInteger(js.Array[Short](1, 0, 1)), //65537
         HashAlgorithm.`SHA-256`).asInstanceOf[KeyAlgorithmIdentifier],
      false, // <---- setting extractable to false
      js.Array(KeyUsage.sign)
    )

Then I think the private key is not readable.

While access to the underlying cryptographic key material may be restricted, based upon the extractable attribute, once a key is shared with a destination origin, the source origin can not later restrict or revoke access to the key.

This blog post "Saving Cryptographic Keys in the Browser" explains that one has to save them in IndexDB:

Because CryptoKey objects are opaque they can’t be placed in localStorage, which only supports simple types. Instead the key store will use IndexedDB, which can clone and store opaque variables. IndexedDB is more complex than localStorage, so dealing with it will be take up much of this post.

If this is possible it might be worth adding that to the README. I know it's a pretty unusual case, but that is why I thought I'd ask.