search

joestubbs / tagent

0 stars 1 forks source link

Disambiguate `path` field for ACL endpoints #20

Open waltermoreira opened 2 years ago

waltermoreira commented 2 years ago

We'd like to clarify a bit more the field path in the JSON requests for the ACL endpoints.

  1. Is it a path relative to root_directory? Does it contain the full path as in the URL (including the prefixes files/ or contents/)?
  2. How to tell whether the user wants an exact match or a regex match?
joestubbs commented 2 years ago

For ambiguity 1), I propose using the full URL path (excluding the base URL). This would allow the ACLs system to be significantly more general and apply to other kinds of API resources. For example, we should be able to apply the ACLs system to the /acls endpoints themselves, to allow managing which subjects can manage the ACLs for the server.

For ambiguity 2), I thought through what I think are the primary use cases, both for file paths and more generally for URLs. I see the primary uses being to manage access on: 1) a specific resource, i.e., a string literal, like /files/list/path/to/foo.txt. 2) all resources under a certain path, like all files in /files/list/some/path or subdirectory or all resources under /acls. 3) a set of resources with a specific prefix or extension in a directory (e.g., all .txt files or all files beginning with the tesxt exam in a directory) 4) a set of resources with a specific prefix/extension in any subdirectory of a directory.

I think we can accomplish all of these with a simpler syntax than regex and one that does not require distinguishing string literals from patterns. I am thinking we can use a glob style syntax and leverage the * character (and ** for subdirectory matching). On Linux/Unix file systems, the * character is special and already has to be escaped, so this means if I put a path like /path/to/*.txt it already means "all .txt files within the /path/to directory", and similarly, /path/**/*.txt means "all .txt files in all subdirectories of the /path directory.

I found the glob crate and was playing with an implementation. The glob::Pattern::new()...matches_with() setting an option require_literal_separator: true appears to do what we want.

What do you think?

waltermoreira commented 2 years ago

Yes! I like both decisions a lot. Particularly, 2) makes it simpler for both the developers and the users, so win-win. And it's what many other things, like .gitignore, .dockerignore, etc., use.