Interact with the device-native key storage (Android Keystore, iOS Keychain).
Note
This plugin is scoped to interact with the device-specific keystore. It assumes that biometrics are set up on the user's device and performs no preflight check before trying to interact with the keystore. You should use the official biometric plugin to checkStatus
before, if you want to make sure (see Usage below).
Platform | Supported |
---|---|
Linux | ❌ |
Windows | ❌ |
macOS | ❌ |
Android | ✅ |
iOS | ✅ |
Add the following to your src-tauri/Cargo.toml
:
[dependencies]
tauri-plugin-keystore = "2"
Then install the JS guest bindings:
pnpm add @impierce/tauri-plugin-keystore
This also works for npm
and yarn
.
- This plugin requires a Rust version of 1.77.2 or higher.
- The minimum supported Tauri version is 2.0.0.
- Android 9 (API level 28) and higher are supported.
First you need to register the plugin with your Tauri app:
src-tauri/src/lib.rs
fn main() {
tauri::Builder::default()
.plugin(tauri_plugin_keystore::init())
.run(tauri::generate_context!())
.expect("error while running tauri application");
}
Afterwards all the plugin's APIs are available through the JavaScript guest bindings:
import { remove, retrieve, store } from "@impierce/tauri-plugin-keystore";
await store("secr3tPa$$w0rd");
const password = await retrieve();
await remove();
The provided functions will fail if the device has no biometrics set up, so you should check the biometric status with the official tauri-plugin-biometric
before using them:
import { checkStatus, type Status } from "@tauri-apps/plugin-biometric";
const biometricsStatus: Status = await checkStatus();
assert(biometricsStatus.biometryType !== BiometryType.None);
This plugin is semantically versioned, but there are some caveats:
- Versioning starts at
v2.0.0
to match the Tauri version it supports (common practice for Tauri plugins). - Breaking changes should be avoided as they would make the plugin go out-of-sync with the Tauri major version.
The next version is determined by semantic-release
which does not recommend making commits during the release process.
When publishing a new npm package to npmjs.com this is circumvented by semantic-release
by pushing the version in the release metadata, so the version
field in package.json
is ignored.
However, crates.io uses the version
field from Cargo.toml
to determine the version. There seems to be no easy way to replace the version number during the publish to crates.io.
This repository provides a workaround for this issue by using a semi-automated release process which decouples building a new release from pushing it to the package registries:
-
Run the release --dry-run Action to let
semantic-release
determine the next version. Take note of the version it produces. -
Manually update the
version
fields in theCargo.toml
andpackage.json
files (omit the"v"
, so just2.1.0
instead ofv2.1.0
). -
Commit the changes using the following commit message (replace the version):
build: release version v1.1.0-alpha.1
-
Open a pull request with the same title as the commit message.
-
After the PR is merged, the actual release Action will run which creates a new release on GitHub and adds a git tag.
-
The publish Action then publishes the packages to npm and crates.io.