[Bug]: Web Executor: Read File: permission issue
- Dominant language
- TypeScript
- Stars
- 4.7k
- Forks
- 388
- PR merge metrics
- No merged PRs in 30d
Description
### What happened?
File system permissions do not appear to persist between sessions.
Here's an example:

As you can see, I get an error `path not allowed on the configured scope` when attempting to read a file.
Here is the project for testing: [Access Control Issue.zip](https://github.com/Ironclad/rivet/files/13900666/Access.Control.Issue.zip)
To reproduce the issue:
1. Open the project
2. Edit the Read Directory node
3. Pick a directory (any directory, something with not too many files in it.)
4. Run the project: this will work fine - you should see the Read File node populating with e.g. "binary (length 123,456)`
5. Save the project and close Rivet
6. Open Rivet and open the same project
7. Run the project: this will fail - you will see an error message on the Read File node.
Best guess:
* the Web Executor uses the File System API to select and authorize access to the folder.
* access is granted for that browser session, enabling Read File to read a file from that directory.
* when reopening the project, permissions do not get restored.
I don't know Tauri, but I would guess it provides a more direct (less restrictive) file system API than the browser provides?
Do you have plans to actually support Tauri on the web? (running in an actual browser?)
If not, you might consider renaming your Web Executor to Tauri Executor and using it's APIs instead?
If you do intend to keep Rivet compatible with the web, you might need another executor, or maybe a shim of sorts, e.g. overriding the File System API prototypes in the Rivet version to remove the web-specific restrictions from the desktop app?
Alternatively, you might want to take a look here:
https://developer.chrome.com/blog/persistent-permissions-for-the-file-system-access-api
it looks like VS Code gets around this issue:

I don't think VS Code was built on Tauri, but this approach might work here as well?
### What was the expected functionality?
File system permissions should persists in the project data.
### Describe your environment
Win 11 Pro
### Relevant log output
_No response_
### Relevant screenshots
_No response_
### Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Contributor guide
Research direction
Start by reproducing the issue with the provided Access Control Issue project, following the Web Executor steps for Read Directory and Read File. Trace how the Web Executor grants permissions and how project data is saved and reopened. Done means a reopened project can read from its previously authorized directory, or the supported limitation is documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- security, web-dev
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100