I think this sounds reasonable, if you want, please open a PR for forbid_file, forbid_directory and reset

Sure thing @amrbashir, but the function names forbid_file and forbid_directory already exist. Those functions add paths to the forbidden set / 'blacklist'. Maybe remove_allowed_file and remove_allowed_drectory would work?

totally forgot about forbid_file and forbid_directory existence, why are these not enough for you? I mean a path is checked against the forbid list before it is checked against the allow list

I am using it in the case of switching between workspaces. If I close a workspace and add it to forbidden, I won't be able to open it back up because forbidden takes priority over allowed. And there's no functionality to remove from forbidden set either. Though, the reset method alone would be enough for my use case.

I see, then a PR to add reset method is enough

A more specific "forget" function with the same api as the allow / forbid functions was requested a lot of times already.
Primarily because as mentioned once a path is forbidden it can never be re-allowed.
And for potentially large apps i feel like a complete reset could be too destructive and potentially lead to users having to keep track of the scope in a second state (or diff the scope before resetting, which is even more annoying since you have to get the pattern types manually before you can allow them) and then re-allowing a huge amount of patterns.

So imho we need both, a complete reset function, and a more granular one for specific patterns.

@FabianLars Is this something that could be added in the mentioned #7371 PR?

If so, how would the function signatures and events look?

pub fn forget_allowed_directory<P: AsRef<Path>>(&self, path: P, recursive: bool) -> crate::Result<()>
pub fn forget_allowed_file<P: AsRef<Path>>(&self, path: P) -> crate::Result<()>
pub fn forget_forbidden_directory<P: AsRef<Path>>(&self, path: P, recursive: bool) -> crate::Result<()>
pub fn forget_forbidden_file<P: AsRef<Path>>(&self, path: P) -> crate::Result<()>

pub enum Event {
  PathAllowed(PathBuf),
  PathForbidden(PathBuf),
  AllowedPathForgotten(PathBuf),
  ForbiddenPathForgotten(PathBuf),
  Reset, // Would a reset event need to be emitted?
}

Also, this is how the reset signature looks in the PR:

pub fn reset<R: crate::Runtime, M: crate::Manager<R>>

// Usage:
scope.reset(&app, &app.config().tauri.security.asset_protocol.scope).unwrap();

Is this something that could be added in the mentioned #7371 PR?

At first i meant to say yes, but with the event enum it will be tricky since it's not marked as non_exhaustive so adding new variants is a breaking change (which means we'd have to add it to v2 instead).

Also, i'd lean towards just having one forget function (well, one for files, one for dirs) which covers both the allowed and forbidden patterns but idk

At first i meant to say yes, but with the event enum it will be tricky since it's not marked as non_exhaustive so adding new variants is a breaking change (which means we'd have to add it to v2 instead).

Yeah a separate PR targeting v2 for the forget method makes more sense.

@FabianLars @amrbashir
And just something to think about for the separate PR: should the app be allowed to "forget" allowed/forbidden scopes defined in the allowed-list/config or just patterns added during runtime?

Not sure what would be the best option but I suggested that a clear function that removes all scope patterns wouldn't be necessary because if the developer intended for a forbidden path to be optional, it shouldn't be added to the tauri config.

I don't necessarily like adding forget function, instead allow and forbid should remove the path from the opposite set

We'll have to be careful with things like the dialog and filedrop scope modifications then, which probably isn't a huge deal.
though i still think a way to prevent something from being allowed could be valuable 🤔

Also, cc @lucasfernog (Amr's last comment)

This is something we need to discuss with the security team too. But personally I prefer having a forget function than dealing with infinite allow/forbid priority (which also polutes the scope if you keep forbidding and allowing a path).