Backend Architecture (Rust & Tauri)
Relevant source files
The following files were used as context for generating this wiki page:The backend of Scripty is built using Rust and the Tauri framework. It serves as the core engine that provides native system functionalities to the React-based frontend. Its primary responsibilities include executing PowerShell scripts with different privilege levels (User, Admin, System), handling file system operations, and managing the application window and updates. The backend exposes a set of commands that can be invoked from the JavaScript frontend, effectively bridging the gap between the webview and the underlying operating system.
Core Structure and Application Entry Point
The application's backend is structured into a binary crate (scripty) and a library crate (scripttool_lib). This separation is a common Rust pattern, particularly on Windows, to avoid naming conflicts.
src-tauri/src/main.rs: This file is the main entry point for the executable. Its sole purpose is to call therun()function from thescripttool_liblibrary. It includes awindows_subsystem = "windows"attribute to prevent a console window from appearing on Windows in release builds.src-tauri/src/lib.rs: This is the core library containing all backend logic, including the Tauri application builder, command definitions, and plugin initializations.src-tauri/build.rs: This file contains a build script that callstauri_build::build(), which is responsible for processing Tauri-specific configurations and code generation during the build process.
The diagram below illustrates the startup flow of the application.
This diagram shows the application startup sequence, from OS execution to the launch of the Tauri application.
Sources: src-tauri/src/main.rs:4-6, src-tauri/src/lib.rs:64-77, src-tauri/build.rs:1-3
Backend Dependencies
The backend relies on several Rust crates defined in Cargo.toml to provide its functionality.
| Crate | Version | Description |
|---|---|---|
tauri | 2 | The core framework for building the cross-platform desktop application. |
tauri-plugin-opener | 2 | A Tauri plugin to open URLs and files with their default programs. |
serde | 1 | A framework for serializing and deserializing Rust data structures, used for communication with the JS frontend. |
serde_json | 1 | Provides JSON serialization and deserialization for serde. |
tauri-plugin-dialog | 2 | A plugin for native system dialogs (e.g., file open, confirmation). |
windows | 0.61.3 | Provides raw bindings to Windows APIs. Likely used for lower-level system interactions. |
tauri-plugin-fs | 2 | A plugin for interacting with the file system. |
tauri-plugin-process | 2 | A plugin for managing child processes. |
tauri-plugin-updater | 2 | A plugin to handle automatic application updates. This is a conditional dependency for non-mobile OSes. |
Sources: src-tauri/Cargo.toml:10-29
Tauri Configuration
Application behavior, window properties, and build settings are defined in tauri.conf.json.
Key configurations include:
productName:(S)criptyversion:0.9.1identifier:com.scripty.app- Window Settings: The main window is configured to be borderless (
"decorations": false) and have a transparent background ("transparent": true), indicating a custom UI is used for window controls. - Updater: The updater is active and configured to check for new releases from a specific GitHub URL. The public key for signature verification is also included.
Sources: src-tauri/tauri.conf.json
Backend Commands (API)
The Rust backend exposes several commands to the JavaScript frontend using the #[tauri::command] macro. These functions form the API layer between the frontend and native capabilities.
| Command | Parameters | Return Value | Description |
|---|---|---|---|
read_ps1 | path: String | Result<(String, String), String> | Reads the content of a .ps1 file at the given path and returns the path and its content. |
open_terminal | content: String | () | Spawns a new PowerShell process and executes the provided script content in the current user's context. |
open_admin_terminal | content: String | () | Spawns a new PowerShell process with elevated (Administrator) privileges to run the script content. |
run_sys_terminal | content: Option<String> | Result<(), String> | Executes a command as the SYSTEM user by extracting and running an embedded syspwsh.exe utility. |
Sources: src-tauri/src/lib.rs:30-62
The following sequence diagram shows a typical interaction where the frontend requests to read a file.
This diagram illustrates the flow when the frontend invokes the read_ps1 command to load a script.
Sources: src/components/Form/Form.jsx:21, src-tauri/src/lib.rs:58-62
Script Execution and Privilege Escalation
A core feature of Scripty is its ability to execute PowerShell scripts with different privilege levels. This is handled by three distinct backend commands.
Admin Execution (open_admin_terminal)
To run a script as an Administrator, the open_admin_terminal command uses PowerShell's built-in Start-Process cmdlet with the -Verb RunAs argument. This triggers a User Account Control (UAC) prompt on Windows, asking the user for elevation.
This flowchart shows how a script is executed with administrator privileges.
Sources: src/components/DetailView/DetailView.jsx:23, src-tauri/src/lib.rs:36-46
System Execution (run_sys_terminal)
Executing a script as the SYSTEM user is more complex. This functionality relies on an embedded executable, syspwsh.exe, which is included directly in the application's binary.
The process is as follows:
- The
syspwsh.exebinary, embedded at compile time, is extracted to the user's temporary directory if it doesn't already exist. - A new command is spawned that executes this extracted
syspwsh.exe. - If script content is provided, it is passed as a command-line argument to
syspwsh.exe.
This flowchart details the mechanism for running a script as the SYSTEM user by extracting an embedded helper executable.
Sources: src/components/DetailView/DetailView.jsx:20, src-tauri/src/lib.rs:8-20, src-tauri/src/lib.rs:48-56
Plugin System and Capabilities
The backend is initialized with several Tauri plugins that extend its core functionality.
// src-tauri/src/lib.rs:66-71
.plugin(tauri_plugin_process::init())
.plugin(tauri_plugin_updater::Builder::new().build())
.plugin(tauri_plugin_fs::init())
.plugin(tauri_plugin_dialog::init())
.plugin(tauri_plugin_opener::init())
These plugins provide sandboxed access to native features. The permissions for these features are defined in src-tauri/capabilities/default.json. This file acts as an allow-list, specifying exactly what the frontend is allowed to do, such as writing to the app data directory (fs:allow-appdata-write-recursive) or controlling the window (core:window:allow-close). This is a key part of Tauri's security model, ensuring the webview has limited and explicit access to the system.
Sources: src-tauri/src/lib.rs:66-71, src-tauri/capabilities/default.json