#Dropping folder does not add to scope
40 messages · Page 1 of 1 (latest)
Does it mention the word "scope"?
it does not, returned "forbidden path" error
Dropping files works, but folders it doesnt
Not sure if expected or a bug?
Can you please post the full error string.
"forbidden path: /Users/revofusion/PersonalFolder"
from ipc://localhost/plugin%3Afs%7Cread_dir
400 error
I got the path from tauri://file-drop event
Are you using Tauri v2?
yes
I'll try to replicate this in an hour. I have to head out for a bit.
Looks like the message has changed but that's still the scope message. You need to allow the path in src-tauri/tauri.conf.json. The bottom of that file should have plugins section which you need to add the fs > scope to similar to below. The first will grant access to the folder itself. The second will grant access to the folder's contents and sub-folder contents.
"plugins": {
"shell": {
"open": true
},
"fs": {
"readDir": true,
"scope": {
"allow": ["$HOME/PersonalFolder", "$HOME/PersonalFolder/**"]
}
}
}
hmm
does somebody remember how v1 behaved?
the plugin doesn't allow it recursively, only the folder and its direct contents which idk how intentional that is
okay found it. it behaved the same 🤔
Can you open an issue on the plugins-workspace repo please?
The error suggests that nothing was allowlisted which is even weirder.
The types were a bit wrong so I'll fix those while addressing the scope modification. Do you think recursive scope modification justifies a config option like the Unix dotfiles matching does? It could be used to tighten security a little on apps that don't need it but my experience with not matching dotfiles is a lot of people seem to not realise the config option even exists.
hmm, i'd go without a config for that
i agree that nobody would notice it and then wonder why it behaves whatever way it behaves
imo always recursively allowlisting folders is an acceptable risk in this context but if you add a note about it in the PR we can ask the other maintainers
Will do. Should drags also modify the allowlist?
nah, only drops
if users wanna have drags allowlisted i'd rather have them do it themselves manually
I've got some notes down on the changes and will make the PR in about 9 hours from now because GitHub is being a pain about 2FA. Basically, the code changes:
https://github.com/tauri-apps/tauri/blob/dev/tooling/api/src/window.ts#L62-L63
| { type: 'hover'; paths: string[]; position: PhysicalPosition }
| { type: 'drop'; paths: string[]; position: PhysicalPosition }
https://github.com/tauri-apps/tauri/blob/dev/tooling/api/src/window.ts#L1736
handler({ ...event, payload: { type: 'drop', paths: event.payload.paths, position: event.payload.position } })
https://github.com/tauri-apps/tauri/blob/dev/tooling/api/src/window.ts#L1743
handler({ ...event, payload: { type: 'hover', paths: event.payload.paths, position: event.payload.position } })
https://github.com/tauri-apps/tauri/blob/dev/core/tauri/src/manager/window.rs#L693
let _ = scopes.allow_directory(path, true);
https://github.com/tauri-apps/plugins-workspace/blob/v2/plugins/fs/src/lib.rs#L95
let _ = scope.allow_directory(path, true);
oh right, i didn't even think about changes in tauri itself. forgot about that
because fs is now its own plugin which also handles the filedrop event for its own scope
Oh, did I miss something in the plugin?
the plugin handles the fs scope, tauri core handles the asset protocol scope
Hm... will look into that before I make the PR. Maybe a draft at first. Found it, added above.
Nice, so these changes will give access to the folder and all subpaths right?
Yes.
Did some further testing just now and it turns out that the fs plugin doesn't receive the drop events. Which explains why the error was saying the path was forbidden, it was never trying to add it to the fs scope.
Filedrop works, just the fs scope isn't extended by it like it's meant to be.
Thank you for debugging this
Is there a PR I can track