Improve the description of path handling in storage scopes. #48
Conversation
|
|
||
| For example, a scope `storage.create:/foo/bar` must **allow** the creation of: | ||
| * a leading directory `/foo` if that path does not exist yet; | ||
| * a directory or file `/foo/bar` if `/foo` is a directory; |
There was a problem hiding this comment.
I would imagine that the authorising agent (the one deciding on the path) knows whether the AuthZ path should be a file or directory. Moreover, this agent might also care what the client does: they want to authorise creating a directory and not a file, or vice versa.
This would not be possible with the above semantics.
For example, suppose a token should allow the client to create/upload exactly one file. : a token with storage.create:/results/my-result.root would allow the client to create a directory /results/my-result.root and subsequently upload as many files as they want.
An alternative approach would be to use the presence or absence of a trailing slash to indicate what kind of object may be created.
For example, in the scenario where /foo exist as a directory but /foo/bar does not exist, then
storage.create:/foo/barauthorises the creation of a filebarbut not a directorystorage.create:/foo/bar/authorises the creation of the directorybarbut not a file.
There was a problem hiding this comment.
Hi, we all agree on this PR and Paul's comment.
Just to be super clear: a storage.create:/foo/bar/ scope also authorises the creation of a /foo/bar/qux file for example
There was a problem hiding this comment.
Hi all,
this proposed semantic change will have to be brought to the attention of all data management MW providers in our community.
There was a problem hiding this comment.
Hiya @maarten-litmaath , please feel free to drop the suggestion if you don't think it has merit (won't be genuinely useful). It was more an observation (of something that might be of interest) than a request that something is change. I don't want to create necessary work for other people.
There was a problem hiding this comment.
I think the idea is interesting enough to try to pursue, while hopefully all MW concerned can still be changed without too much hassle.
There was a problem hiding this comment.
I have opened #50 for continuing this discussion. For now, I will merge the PR as-is, thanks!
This PR proposes additional clarifications for the handling of paths in storage scopes, based on suggestions in #21, as well as an improved formulation of the introductory paragraph about the topic.
Closes: #21