Add support for WASM targets running in a custom runtime #83
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
Currently, on WASM targets, the
zxcvbn
crate can only be used if the host environment is JavaScript, such that functions such asjs_sys::new_0()::get_time()
would be available through bindings generated by e.g. wasm-bindgen.Rationale
Not all code compiled to WASM is run in a JavaScript runtime.
One example is the 1Password Go SDK, which uses Extism to communicate with a Wazero runtime, which does not have the JS bindings available.
For context, this project leverages a Rust core (where
zxcvbn
is used to determine the password's strength, when creating or updating 1Password items) compiled to WASM. Calls to it are made from the Go host env.In situations where these system functions are not available, placeholders for it have to be injected into the runtime by the host.
In the Go code, injecting such a function would look similar to:
https:/1Password/onepassword-sdk-go/blob/main/internal/imported.go#L31-L38
Thought process
This PR addresses this issue by allowing the host environment to inject its own implementation for the
now
function. It requires the environment to export aunix_time_milliseconds_imported
, returning the unix timestamp in milliseconds.This change is fully backwards compatible, and it requires that the consumers of the crate explicitly opt in to provide this custom implementation by activating the
custom_wasm_env
feature. In the absence of this feature, calls to zxcvbn would panic.How to test
Code review, to begin with, would be greatly appreciated.
For functional review, I have put together a test repository where the new behaviour can be validated.
See testing notes in the README: https:/hculea/zxcvbn-test
Additional information
In the scope of this PR, I have also:
getrandom
dependency from the wasm32 dependency tree, as it was not being used anywhere#![forbid(unsafe_code)]
linter, as injecting a custom function requires the execution of unsafe code