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

[mindplay-dk]

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

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

[abrenneke]

It doesn't actually use the file system APIs because those aren't present in the default WebViews that Tauri uses, they're too new. It does use the Tauri APIs, but those have special security associated with them too so that the browser can't just read any file on your file system. It's been buggy for a long time though, I'll see what I can do to improve it.

[abrenneke]

If not, you might consider renaming your Web Executor to Tauri Executor and using it's APIs instead?

I would if Tauri's web APIs supported streaming, but they don't, so I have to use the browser fetch API.