* feat(sql): add autoCreate option to Database.load
Add utoCreate option to Database.load allowing users to disable implicit database creation when loading a database.
Closes#299
* fix(sql): fix unused variable without a database feature
* refactor(sql): share the database existence check between drivers
* fix(sql): don't report a failed existence check as a missing database
* fix(sql): name the database as passed, without password, in the missing database error
* fix(sql): don't create the app config dir when autoCreate is false
* refactor(sql): use the LoadOptions default for missing options
* test(sql): cover autoCreate and password redaction
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* feat: adding the ability to encrypt/decrypt data based on the biometric auth
Adding the method biometricCipher() that allows to use the biometric authentication to use a generated key from android that can be accessed only through the biometric authentication. The method uses this key to encrypt/decrypt the data provided by the caller in the "options" parameter, with "dataToEncrypt" or "dataToDecrypt" filled.
Changes were done both on Kotlin, Rust and JS sides.
* Improving the way we encrypt data by allowing only if the biometric was successful.
* Adding a warning on the JS side
* Adding doc changes in readme.md
* Adding doc changes in readme.md
* Update README.md - it was updated incomplete
* update docs
* enhance error handling
* update example
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
On Android, cancel() called destroy() first, and destroy() sets
savedInvoke to null, so the savedInvoke?.reject("cancelled") that
follows was a no-op. The pending scan() promise was never settled and
callers awaiting it were stranded, which is especially bad in windowed
mode where the page background stays transparent.
Reject the pending invoke before tearing the camera down, matching the
order the iOS implementation already uses.
When initializing the plugin's runtime scope in .setup, pass
equire_literal_leading_dot from config to FsScope::Scope instead of using FsScope::default() so that paths allowed dynamically via s_scope().allow_directory() inherit the configured value.
Closes#3699
* experimenting...
Signed-off-by: BestCodes <106822363+The-Best-Codes@users.noreply.github.com>
* omit unconfirmed fact from .changes
Signed-off-by: BestCodes <106822363+The-Best-Codes@users.noreply.github.com>
* fix(notification): send untracked Linux notifications on the shared connection
Holding notify-rust's handle with `on_close` blocked an async runtime
worker until the server closed the notification, and opened a D-Bus
connection per notification. Since GNOME keeps notifications in its tray,
a handful of them could stall every async task of the app.
Send every notification on the connection the plugin already keeps open
for its action listener instead: it keeps the sender's name alive for
GNOME at the cost of a single connection and thread, and the listener
runs the `on_close` callbacks.
* fix(notification): offer `on_close` on the BSDs too
The BSDs share the D-Bus implementation with Linux, including the GNOME
issue, so gate `NotificationBuilder::on_close` like the rest of that
implementation and document when the callback runs.
* fix(notification): run `on_close` without the tracker lock held
The callback ran on the listener thread while the guard of the callback
map was alive, and a panic in it ended that thread, which then reported
no action of any notification for the rest of the app's life. Take the
callback out of the map before running it and contain its panics.
* fix(notification): use the covector package names in the change files
`tauri-plugin-notification` and `@tauri-apps/plugin-notification` are
not packages of .changes/config.json, so covector refused the change
file. Use `notification` and `notification-js`, and record the new
`on_close` API as a feature of its own.
Also let `on_close` take an `FnOnce`, since it runs at most once.
---------
Signed-off-by: BestCodes <106822363+The-Best-Codes@users.noreply.github.com>
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* Fix incorrect error being reported in certain cases with fallback allowed
* Add change file
* Rework original solution due to overlooking authenticators logic on API >= `Build.VERSION_CODES.R`
* fix(biometric): don't cast the Android error message to String
* fix(biometric): report a missing device credential before showing the Android prompt
Replaces the override of ERROR_NO_BIOMETRICS in the prompt callback, which keyed on
the caller's flag rather than the device state and missed the no-hardware errors.
* fix(biometric): load the missing device credential message from a string resource
* chore(biometric): drop stray semicolon
* docs(biometric): mention the passcodeNotSet error code rename in the change file
* test(e2e): cover the biometric passcodeNotSet rejection on Android
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
`convertToRustHeaders` replaced `options.headers` of the object passed to
`check`, `download` and `downloadAndInstall` with an array of entries. The
headers are now converted into the invoke payload only (`toRustHeaders`).
E2E: `check` leaves the options object untouched.
plugins/updater/guest-js/index.ts
- `tempdir_in(..)?` and `metadata()?` returned early on the first location
that failed (e.g. a non-writable `/tmp`), so the cache dir and the
directory next to the AppImage were never tried. Failures now move on to
the next location, as the deb/rpm path already did.
- The candidate list was duplicated between the AppImage and deb/rpm paths;
both now use `tmp_dir_locations`, which also no longer unwraps the parent
of the app path (`extract_path.parent().unwrap()`).
Compile-checked with clippy in a Linux container (default features).
plugins/updater/src/updater.rs
* fix(updater): derive the Windows installer launch error from ShellExecuteW
A failed `ShellExecuteW` was reported with `std::io::Error::last_os_error()`,
but `ShellExecuteW` reports failures through its return value (`SE_ERR_*`),
not reliably through `GetLastError`, so the message could be meaningless. The
return value is now mapped to an error (the codes shared with Win32 errors,
like `SE_ERR_ACCESSDENIED` when the UAC prompt is declined, keep their OS
message).
Running `on_before_exit` only once the installer launched changes when a
public hook runs and is left for v3.
Compile-checked only (clippy for x86_64-pc-windows-msvc).
plugins/updater/src/updater.rs
* use constants
Each `Update.download()` overwrote `this.downloadedBytes` without closing the
previous resource, so the whole previous update payload stayed in the webview
resources table. The previous resource is now closed once the new download
succeeded (so a failed retry still leaves the earlier download installable).
Not covered by e2e: the fixture manifest has no valid signature, so a
download can never succeed there.
plugins/updater/guest-js/index.ts
* fix(updater): warn when the update download URL is not https
`validate_endpoints` enforces `https` for the endpoints, but not for the `url`
of the manifest, so the artifact can be downloaded in plaintext. Enforcing it
would break existing releases (left for v3); `Update::download` now logs a
warning instead, unless `dangerousInsecureTransportProtocol` is enabled.
plugins/updater/src/updater.rs
* Apply suggestion from @lucasfernog
`#[cfg(mobile)] fn install_inner` returned `Ok(())` without doing anything.
`check` already fails with `UnsupportedOs` there unless a Rust caller sets a
custom target, in which case a download was followed by a successful
"install" that did nothing. It now returns `Error::UnsupportedOs`, the error
`check` uses.
Verified with clippy for aarch64-linux-android (the iOS build needs the Swift
package, which does not build here).
plugins/updater/src/updater.rs
* fix(updater): check the AppImage update payload before installing it
Without the `zip` feature the gz check was compiled out and a signed
`.tar.gz` was written verbatim over the AppImage, and any other payload
without the gz magic (e.g. a `.deb` from the same release, or the fallthrough
when `bundle_type()` is `None`) was written the same way, corrupting the app.
The payload is now checked before the current AppImage is moved: a gzip
archive requires the `zip` feature, and anything else must be an ELF
executable (which every AppImage is); otherwise `InvalidUpdaterFormat` is
returned. The `Cursor`/`OsStr` imports are gated so that the crate builds
warning-free without `zip` on Linux too.
Compile-checked with clippy on macOS, Linux (container) and Windows, each
with and without the `zip` feature.
plugins/updater/src/updater.rs
* tests
* fix(deep-link): honor XDG failures and unregister associations
* test(deep-link): isolate other application handlers
* chore: satisfy release metadata and test header checks
* fix(deep-link): gate XDG helpers to Linux
The plugin only supports Linux, so FreeBSD builds warned about dead code.
* refactor(deep-link): add run_command helper
Share the spawn, status check and logging for XDG commands.
* refactor(deep-link): share desktop file list helpers
register and unregister now edit MimeType lists the same way.
* fix(deep-link): keep desktop file quoting on register
Parse raw values so a quoted Exec matches and isn't rewritten each time.
* fix(deep-link): clean mimeapps.list first on unregister
A failing update-desktop-database no longer leaves the app as the default.
* fix(deep-link): keep mimeapps.list comments on unregister
Edit it line by line instead of re-serializing it through rust-ini.
* fix(deep-link): skip cache refresh when nothing to unregister
Only run update-desktop-database if the desktop file changed or the cache still lists the app.
* fix(deep-link): treat no default handler as unregistered
xdg-mime exits with 4 on KDE and LXQt when no handler is set.
* fix(deep-link): tolerate padded xdg-mime query output
Compare the trimmed first line instead of the raw output.
* test(deep-link): run XDG tests in CI
Drop #[ignore], skip when the tools are missing, and install them on Linux CI.
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* fix(single-instance): propagate D-Bus setup and handoff errors
* chore: satisfy release metadata and test header checks
* fix(single-instance): launch normally without a D-Bus session bus
Log a warning instead of failing setup when the session bus is unreachable, and add context to handoff errors.
* ci: run the single-instance D-Bus test under dbus-run-session
Run it in test-rust on Linux and keep it out of the updater integration job, which has no session bus.
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* fix(fs): allow open, seek and fstat in the write permission sets
The stream path of writeFile calls `open`, which only the nested command
list of `allow-write-file` granted (plugins/fs/permissions/write-all.toml,
write-files.toml), so `fs:allow-appdata-write-recursive` and the other
write sets rejected streamed writes; seek/fstat were missing for
FileHandles created under these sets.
Adds open, seek and fstat to write-all and write-files. This widens the
write sets slightly (open is already implied by allow-write-file); the
generated reference does not list set members, so nothing to regenerate.
* use dependencies instead
In plugins/fs/src/file_path.rs SafeFilePath::from_str, any string that
parsed as a URL with a scheme of 2+ characters was a URL, so a relative
path such as `notes:2024.txt` became a cannot-be-a-base URL and failed
with InvalidPathUrl.
Cannot-be-a-base URLs are now parsed as paths. The scheme-agnostic
url.to_file_path() stays: its result is scope checked (not a bypass).
Unit test for the parser; e2e spec writes and reads such a file (not on
Windows, where `:` is not allowed in file names).
* fix(updater): skip a backup location the AppImage cannot be renamed into
Two mounts of one file system share st_dev, so install_appimage could
pick a bind-mounted or private temp dir and then fail every install with
EXDEV. Move on to the next location instead; the last one is the
AppImage's own directory.
* Apply suggestion from @lucasfernog
---------
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
* fix(ios): make `init_plugin_*` entry points public so release builds link on Xcode 27
Xcode 27's SwiftPM (Swift Build) gives non-public @_cdecl functions local
visibility in release builds, so each plugin's init_plugin_* is undefined
when Rust links. Mark them public in the 11 plugins with an iOS part.
See tauri-apps/tauri#16130
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Apply suggestion from @lucasfernog
---------
Co-authored-by: takakix2 <1370181+takakix2@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
* Update windows.rs
* Create single-instance-non-unicode-args.md
* fix on linux and windows too
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* feat(shell): add process group spawn option (fix#1332)
Add a `processGroup` boolean option to the shell plugin's spawn command.
When enabled, the child process is spawned in its own process group (POSIX)
or job object (Windows) using the `process-wrap` crate, so that killing
the child also kills the entire process tree.
This fixes the issue where programs like PyInstaller wrappers spawn a
child process that gets orphaned when Tauri kills the parent.
* test(shell): add PyInstaller simulation tests for process group kill
Add end-to-end tests that reproduce the exact scenario from issue #1332:
a wrapper process (like PyInstaller's bootloader) spawns a grandchild.
- Without process_group: killing the wrapper orphans the grandchild
- With process_group: killing the wrapper also kills the grandchild
* refactor(shell): drop redundant cfg gates, trim process-wrap features
Address review feedback on #3351:
- Remove `#[cfg(any(unix, windows))]` gates on `ChildKind::ProcessGroup`,
the kill/pid match arms, and the spawn block, plus the now-dead
`#[cfg(not(any(unix, windows)))]` fallback. That cfg only excluded wasm,
which this plugin never builds for.
- Set `default-features = false` on process-wrap and enable only the
features actually used: std, process-group (unix), creation-flags and
job-object (windows). Drops kill-on-drop, process-session, and tracing.
* fix(shell): enable process-wrap tracing feature, fix CI formatting and changefile
- Add `tracing` feature to process-wrap: with default-features = false its
Windows job_object.rs calls `debug\!` unconditionally while the import is
gated behind `#[cfg(feature = "tracing")]`, failing the Windows build with
"cannot find macro `debug`".
- Reformat process/mod.rs assertions to satisfy `cargo fmt --check`.
- Reindent the process-wrap features array to 2 spaces for taplo.
- Use covector package keys (`shell` / `shell-js`) in the change file so the
check-change-files and covector status jobs pass.
* refactor(shell): unify child handling on process-wrap, drop SharedChild
Collapse the ChildKind enum and the per-platform GroupChild types into a
single process-wrap-backed child. The command always spawns through
StdCommandWrap; the process_group flag is now just an optional wrapper
rather than a switch into a separate child type.
This drops the shared_child dependency and resolves two review notes:
the Unix path no longer hand-rolls killpg, and kill() now goes through
process-wrap's kill (start_kill + wait), which reaps the entire process
group instead of only signalling it.
A background thread polls try_wait to surface the exit status, since
process-wrap's wrappers only expose &mut self wait methods (the reason
SharedChild was used on Unix in the first place).
* chore(example): add process group toggle to shell view
* fix(shell): pass typed creation flags to process-wrap on Windows
`process_wrap::std::CreationFlags` is a newtype over the `windows` crate's
`PROCESS_CREATION_FLAGS`, not a raw `u32`, so the Windows build failed to
compile. Depend on `windows` (already in the tree via `tauri`, pinned to the
same 0.61 that `process-wrap` links against) and use its `CREATE_NO_WINDOW`
constant, which drops the hand-rolled magic number.
The wrap is still required: `JobObject::pre_spawn` calls `creation_flags` and
would otherwise clobber the `CREATE_NO_WINDOW` set at construction.
* perf(shell): block on child exit instead of polling try_wait
The switch from `SharedChild` to `process-wrap` moved the child behind a
mutex, since `StdChildWrapper`'s wait methods take `&mut self` while both
the wait thread and `CommandChild::kill()` need access. A blocking wait
would hold the lock for the child's whole lifetime and starve `kill()`,
so the wait thread polled `try_wait` every 10ms instead.
Block on the raw process outside the lock using a wait that does not reap
(`waitid` with `WNOWAIT` on unix, `WaitForSingleObject` on windows), then
take the lock once to let process-wrap collect the exit status. This is
the same technique shared_child uses internally, applied on top of
process-wrap's kill/reap semantics. No new dependencies or Cargo features
are required.
`kill()` reaps the child while holding the lock, so the raw wait can lose
that race and return ECHILD. That means the exit status is already cached
in the wrapper, so it is treated as success and the status is collected
via `try_wait`. Without this guard, a stress test of 300 spawn+kill
cycles produced 36 Error events in place of Terminated; with it, none in
900 cycles. The `try_wait` loop stays as a defensive fallback, though in
practice the first call succeeds immediately.
Mean latency for `Command::output()` on macOS (debug, 30 iterations of
`echo`) drops from 13.22ms to ~1.8ms, and 10 idle 5s children cost ~11ms
CPU total instead of ~75ms with the poll loop.
* fix(shell): keep CREATE_NO_WINDOW on process-group children (windows)
process-wrap's CreationFlags/JobObject coordination is broken during
spawn (watchexec/process-wrap#35): JobObject::pre_spawn cannot see the
CreationFlags wrapper, so it overwrote our flags with just
CREATE_SUSPENDED and process-group children flashed a console window.
Register CreationFlags(CREATE_SUSPENDED | CREATE_NO_WINDOW) after
JobObject so its pre_spawn runs last and wins. CREATE_SUSPENDED is kept
so the child cannot spawn grandchildren before job assignment; the same
upstream bug keeps wrap_child's resume check from seeing it, so the
child is still resumed.
* test(shell): run the process-tree kill tests on windows
Add a powershell variant of the pyinstaller simulation script and lift
the unix-only gates on the process-group tests, so the windows job in
test-rust exercises the job-object spawn/kill path instead of skipping
it. Both pyinstaller tests now also assert that a Terminated event is
still delivered after kill().
* Update plugins/shell/src/process/mod.rs
Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
* Update .changes/shell-process-group.md
Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
* Update plugins/shell/src/process/mod.rs
Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
* Delete .changes/shell-wait-no-poll.md
* refactor(shell): replace process-wrap with shared_child and an inlined job object
Use std process groups on unix and a job object on windows, with
shared_child handling wait and kill on all platforms.
* fix(shell): kill the process group even after its leader exited
CommandChild::kill returned early once the direct child had been reaped,
so killpg/TerminateJobObject never ran and anything the child left running
in its process group or job object survived, including on app exit.
Adds a launcher-style test (the child starts a grandchild and exits) that
runs on Windows, Linux and macOS.
* fix(shell): restore Debug on CommandChild
Dropping the derive was a breaking change for downstream types that derive
Debug and hold a CommandChild.
* fix(shell): don't block the main thread in the kill command
CommandChild::kill now waits for the child to exit, and the sync kill
command ran it on the main thread while still holding the children lock.
Make the command async and release the lock before killing.
---------
Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
In plugins/fs/src/commands.rs, start/stop_accessing_security_scoped_resource
only handled SafeFilePath::Url, so a plain path was a silent no-op
although the JS docs say "path or file:// URL" (and
Fs::stop_accessing_security_scoped_resource accepts paths).
Absolute paths are now converted to file:// URLs first; relative paths keep
being ignored. iOS-only code: formatted but not compiled here (the iOS
tauri build script fails in this environment).
In plugins/fs/src/commands.rs resolve_path / is_forbidden, only paths
that already existed were canonicalized, so a new file below a symlinked
directory in the scope was matched by its unresolved path and written
outside of the scope. Relative symlink targets were resolved against the
process CWD, only the link target was checked against deny patterns, and
resolution errors made is_forbidden fail open.
resolve_path now computes the real path (canonical nearest existing
ancestor + remaining components, following dangling symlinks relative to
their parent, bounded to 40 links) and checks it against the allow and deny
patterns; deny patterns also match the path as given. Resolution errors
fail closed. Unit tests cover symlinked ancestors, relative and dangling
links and loops.
In plugins/fs/android/src/main/java/FsPlugin.kt getFileDescriptor, for
uncompressed assets AssetManager.openFd returns an AssetFileDescriptor
whose parcel descriptor is the whole APK; its startOffset/length were
dropped and Rust read from offset 0, i.e. APK bytes. Only compressed
assets (openFd throws) took the cache copy path.
All assets now use the cache copy path. The cache file path is also checked
to stay below cacheDir/_assets. Kotlin not compiled here: unverified, needs
an on-device check.
In plugins/fs/src/lib.rs on_event, every path dropped onto any window is
added to the global runtime scope, directories recursively, with no
opt-out.
Adds the `scopeDroppedPaths` plugin config option (default true, the
current behaviour) so apps can turn it off. Changing the default or
scoping it per window is deferred to v3.
In plugins/fs/src/android.rs resolve_content_uri, a null `fd` from
getFileDescriptor (openAssetFileDescriptor returning null, e.g. for
virtual files) hit unimplemented!() and panicked inside the command handler.
It now returns an Unsupported I/O error. Also switches the two
io::Error::new(Other, ..) calls to io::Error::other, which clippy flags on
the Android target. Checked with cargo clippy --target aarch64-linux-android.
In plugins/fs/src/lib.rs OpenOptions, custom_flags was deserializable
from the `open` command arguments even though it is not in the TS types,
so a webview with a read-only permission set could pass arbitrary open(2)
flags such as O_TRUNC.
The field is now #[serde(skip)]; Rust callers still set it through
OpenOptionsExt. Rejecting write/truncate/create options of `open` under
read-only sets changes permission semantics and is deferred to v3.
In plugins/fs/src/commands.rs seek, `SeekFrom::Start(offset as u64)`
turned -1 into u64::MAX. The offset is now converted with u64::try_from
and a negative one is an error. E2E spec added.
In plugins/fs/src/commands.rs read_until_bytes / LinesBytes, the line
feed sequence was matched at any byte offset, so UTF-16LE "ਗĀ"
(17 0a 00 01) or UTF-16BE "Āਗ" (01 00 0a 17) split mid code unit and every
following line was decoded misaligned.
Line feed and carriage return sequences now only match on a multiple of
their length from the start of the line. Unit tests with both examples
(they fail without the fix).
In plugins/fs/guest-js/index.ts writeFile, the stream path opened the
file with {write, create} but no truncate, unlike the buffer path which
truncates unless `append` is set (commands.rs write_file_inner), so
shorter content left stale trailing bytes.
The stream path now passes `truncate: !options?.append`. api-iife.js
regenerated. E2E spec covers overwrite and append with a stream.
In plugins/fs/src/commands.rs read, `vec![0; len]` used the length sent
by the webview as is, so a huge `len` aborted the process on allocation
failure, and the whole buffer (not only the bytes read) was sent back.
The length is now capped to the rest of the file (at least 64 KiB) for
regular files and to 64 MiB otherwise, the allocation uses try_reserve so a
failure is an error, and the buffer is truncated to the bytes read. The JS
side only ever used the first `nread` bytes. Unit test for the cap.
* ci: only run what a change affects, consolidate jobs
- detect affected plugins from changed files and Cargo.lock dependency trees
- test/lint Rust per platform in shards instead of one job per plugin
- fold check-generated-files into lint-javascript, fmt into a single job
- skip fat LTO in integration test builds, single ABI in test-android
* ci: run e2e on bumps, use published tauri CLI, PR-safe pnpm cache
- trigger e2e on Cargo/pnpm lockfile and manifest changes
- install the latest 2.x tauri-cli with cargo-binstall in integration tests
- add setup-pnpm action: restore the store everywhere, save only on v2/v3
* fix clippy, ios build
* fix bumps [skip ci]
