Ironclad / Ironclad/rivet

[Bug]: Web Executor: Read File: permission issue

Open
#308 2 comments 0 reactions 0 assignees View on GitHub
bug
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:

![image](https://github.com/Ironclad/rivet/assets/103348/d4d7b9b5-236b-4195-97c1-530b9a3b058f)

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:

![image](https://github.com/Ironclad/rivet/assets/103348/ed315961-6f52-4316-b024-2770dce605bd)

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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.