zxcvbn-rs icon indicating copy to clipboard operation
zxcvbn-rs copied to clipboard

Add support for WASM targets running in a custom runtime

Open hculea opened this issue 8 months ago • 5 comments

Background

Currently, on WASM targets, the zxcvbn crate can only be used if the host environment is JavaScript, such that functions such as js_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 (wherezxcvbn 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://github.com/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 a unix_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://github.com/hculea/zxcvbn-test

Additional information

In the scope of this PR, I have also:

  • removed the getrandom dependency from the wasm32 dependency tree, as it was not being used anywhere
  • removed the #![forbid(unsafe_code)] linter, as injecting a custom function requires the execution of unsafe code

hculea avatar Jun 03 '24 12:06 hculea