Implement Random#javaSecuritySecureRandom on Scala.js#2906
Implement Random#javaSecuritySecureRandom on Scala.js#2906vasilmkd merged 4 commits intotypelevel:series/3.3.xfrom
Random#javaSecuritySecureRandom on Scala.js#2906Conversation
|
|
||
| import scala.scalajs.js | ||
|
|
||
| private final class SecureRandom extends java.util.Random { |
There was a problem hiding this comment.
If this gets called SecureRandom, the algebra in #2902 will need another name.
There was a problem hiding this comment.
Oh yeah. We can rename it UnsafeSecureRandom or JdkSecureRandom.
There was a problem hiding this comment.
I wouldn't call it Jdk when it doesn't come from one, but it's private. I just mostly want it to be called something else. 😆
There was a problem hiding this comment.
@armanbilge Do you want to do the renaming now, or should we press on? Otherwise, this is good to go.
There was a problem hiding this comment.
I'll rename it JavaSecureRandom.
| private val nextBytes: Int => js.typedarray.Int8Array = | ||
| if (js.typeOf(js.Dynamic.global.crypto) != "undefined") // browsers |
There was a problem hiding this comment.
There's a trade-off initializing this in the class instead of the companion object. Caching is good, but this is not unreasonable if SecureRandom instances are not created very often.
Lazy initialization is important for environments that don't have any secure random capability, since there is no reasonable fallback implementation we can use in those situations.
3 participants
Fixes #2902 by implementing our own
java.security.SecureRandomshim that delegates to browser and Node.js crypto APIs.While working on this I noticed there are other APIs that won't link on Scala.js, like the thread local stuff. Those really should be moved to platform traits in a PR targeting series/3.x.