Summary
Switching workspaces expands the asset protocol scope but never removes the previous root. The JavaScript dialog API also automatically adds selected paths to the asset and filesystem scopes. After several workspace switches, every previously selected directory remains readable by the webview for the life of the process.
Evidence
src-tauri/src/commands.rs:21-23 calls allow_directory for each selected root.- The old workspace watcher is dropped, but its asset scope is not revoked.
SpikeScreen.tsx selects the directory through @tauri-apps/plugin-dialog.
Tauri's forbid_directory takes precedence permanently, so simply forbidding the old root would prevent cleanly reopening it later.
Proposed change
Choose an asset-serving design with an explicit active-workspace lifetime. The preferred option is a custom protocol whose handler canonicalizes every request and validates it against the current root. Alternatives must support both revocation and later reopening without restarting the application.
Move the workspace picker to Rust so the JavaScript dialog plugin does not independently widen asset scope.
Acceptance criteria
- After switching from workspace A to workspace B, the webview cannot load an asset from A.
- Workspace A can be selected again later without restarting the application.
- Asset requests through symlinks cannot escape the active root.
- Tests cover select A, switch to B, reject A, and reopen A.
References
Summary
Switching workspaces expands the asset protocol scope but never removes the previous root. The JavaScript dialog API also automatically adds selected paths to the asset and filesystem scopes. After several workspace switches, every previously selected directory remains readable by the webview for the life of the process.
Evidence
src-tauri/src/commands.rs:21-23callsallow_directoryfor each selected root.SpikeScreen.tsxselects the directory through@tauri-apps/plugin-dialog.Tauri's
forbid_directorytakes precedence permanently, so simply forbidding the old root would prevent cleanly reopening it later.Proposed change
Choose an asset-serving design with an explicit active-workspace lifetime. The preferred option is a custom protocol whose handler canonicalizes every request and validates it against the current root. Alternatives must support both revocation and later reopening without restarting the application.
Move the workspace picker to Rust so the JavaScript dialog plugin does not independently widen asset scope.
Acceptance criteria
References