Core plugin permission identifiers prefix change
In Tauri 2.0, core plugin permission identifiers must be prefixed with 'core:'. For example, 'path:default' becomes 'core:path:default', 'event:default' becomes 'core:event:default', 'window:default' becomes 'core:window:default', 'app:default' becomes 'core:app:default', 'image:default' becomes 'core:image:default', 'resources:default' becomes 'core:resources:default', 'menu:default' becomes 'core:menu:default', and 'tray:default' becomes 'core:tray:default'.
core:default permission set
A new special 'core:default' permission set has been added in Tauri 2.0 that includes all default permissions for all core plugins. This can be used in capability configurations as a replacement for listing all individual core permissions.
Window-specific security capabilities using windows field
Security capabilities can be restricted to specific windows by adding a windows field to the capability JSON file containing an array of window labels that should have access to that capability.
Platform-specific capabilities using platforms field
Security capabilities can be restricted to specific platforms by adding a platforms field to the capability JSON file. The valid platform identifiers are: linux, windows, macos, android, and ios.
Capability file structure with required fields
A capability file must contain: identifier (string), description (string), local (boolean), windows (array of window labels), permissions (array of permission strings), and optionally platforms (array of platform names).
Filesystem read permission string format
Filesystem read permissions use the format fs:allow-home-read to allow read access to the home directory.
Organizing capabilities by category in separate files
It is recommended to split security capabilities into separate JSON files in the src-tauri/capabilities directory organized by category, such as filesystem.json and dialog.json, for better maintainability and security granularity.
Dialog permission string format
Dialog permissions use the format dialog:allow-ask to allow opening Yes/No dialog boxes.
Autogenerated permissions in build.rs
Permissions can be autogenerated by defining command names in the COMMANDS const array in build.rs using snake_case command names. Tauri automatically generates 'allow-$commandname' and 'deny-$commandname' permissions for each command listed.
Default permission in plugins
The default permission is a special permission set with identifier 'default' that is recommended for enabling required commands by default. It should contain permissions needed for the plugin to be functional, such as the 'allow-request' permission for the http plugin.
Plugin command permissions requirement
By default, plugin commands are not accessible by the frontend and return a denied error rejection. Commands must have permissions defined in JSON or TOML files inside the permissions/ directory to be accessible.
Permission definition structure
A permission describes privileges for plugin commands with an identifier, description, and allow/deny command lists. Each permission can define scope objects that allow or deny specific functionality either command-specific or globally to the plugin.
Command scope usage in plugins
Command-specific scopes are read using tauri::ipc::CommandScope struct with methods allows() and denies(). Global scopes (when no commands are specified) are read using tauri::ipc::GlobalScope struct. It is recommended to check both global and command scopes for flexibility.
Permission sets grouping
Permission sets are groups of individual permissions that provide higher-level abstraction. They have an identifier, description, and a permissions array containing individual permission names. They help users manage plugins at a higher level of abstraction.
iOS plugin permissions implementation
On iOS, override the checkPermissions and requestPermissions functions in the plugin class. The checkPermissions function should return a map of permission names to PermissionState values. The requestPermissions function should handle the actual permission request and then resolve with the updated permission states.
Plugin permission command invocation from Rust
From Rust, use the run_mobile_plugin method on PluginHandle to call checkPermissions and requestPermissions commands. Pass an empty tuple () for checkPermissions and a struct with boolean fields matching permission aliases for requestPermissions.
Android plugin permissions declaration
On Android, define the list of permissions needed by adding a permissions array to the @TauriPlugin annotation. Each permission is declared with Permission(strings = [Manifest.permission.PERMISSION_NAME], alias = "aliasName"). Tauri automatically implements checkPermissions and requestPermissions commands for the plugin.
Plugin permission command invocation from JavaScript
From JavaScript, call checkPermissions and requestPermissions commands using the format 'plugin:<plugin-name>|checkPermissions' and 'plugin:<plugin-name>|requestPermissions'. The requestPermissions command accepts a permissions array parameter containing the permission aliases to request.
v2 permissions system replaces v1 allowlist with Access Control List
Tauri v2 replaces the v1 allowlist with a new Access Control List-based approach for command access. The new system allows fine-grained configuration of commands with scopes that can be specific to windows or remote URLs, and supports multiwindow.
File System plugin default capability permissions example
A typical File System plugin capability configuration includes permissions like `fs:default` for basic access and command-specific permissions like `fs:allow-exists` with scope entries specifying allowed paths as objects with a `path` property.
File System plugin permission identifier format
File System plugin permission identifiers follow the format `fs:allow-<command>` or `fs:deny-<command>` for command-specific permissions, or `fs:scope` for global scope permissions applied to all fs commands.
Store plugin default permission capability
The Store plugin requires the permission 'store:default' to be added to the capabilities configuration in src-tauri/capabilities/default.json to enable access to potentially dangerous plugin commands.
Plugin permissions security model
By default all potentially dangerous plugin commands and scopes are blocked and cannot be accessed. Permissions must be explicitly configured in the capabilities configuration file to enable them.
Process plugin default permission
The process plugin requires the permission 'process:default' to be added to the capabilities configuration in src-tauri/capabilities/default.json to enable access to plugin commands.
Deep link plugin permissions configuration
Deep link plugin commands are blocked by default. To enable them, configure permissions in capabilities. The required permissions are `core:event:default` for listening to deep link events and `deep-link:default` for the plugin. Configure in the capabilities JSON file.
Global Shortcut plugin default permission blocking
By default, all potentially dangerous plugin commands and their scopes are blocked and inaccessible. Permissions must be explicitly enabled in the capabilities configuration to use Global Shortcut functionality.
Window State plugin default permission
The Window State plugin requires the permission 'window-state:default' to be added to the capabilities configuration (src-tauri/capabilities/default.json) to enable potentially dangerous plugin commands.
Global Shortcut required capabilities
The Global Shortcut plugin requires the following permissions in capabilities configuration: global-shortcut:allow-is-registered, global-shortcut:allow-register, and global-shortcut:allow-unregister. These must be explicitly added to the permissions array in the capability file.
Haptics capability configuration example
A mobile capability for Haptics should be defined in src-tauri/capabilities/mobile.json with schema reference to ../gen/schemas/mobile-schema.json, identifier 'mobile-capability', windows set to ["main"], platforms set to ["iOS", "android"], and permissions array containing the four haptics permission names.
Haptics plugin default permission status
By default, all potentially dangerous plugin commands and their scopes are blocked and inaccessible. Permissions must be enabled by changing access rights in the capabilities configuration.