-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Write agent-specific ACL rules to a given ACL LitDataset #191
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This implements all the features in the acceptance criteria, there are just a couple of open questions that e might want to consider, as they will come back when we extend these features to groups for instance.
This approach expects the developer to specify the ACL document in which the access right should be added. How complex would it be to only require the developer to specify the target resource, webid and desired access modes, to discover the appropriate ACL document automatically, and to modify the access rights without introducing side-effects ? The present functions could still be exposed for optimizations, when one already has the link to the target ACL document, but a function of a higher abstraction that does the ACL discovery under the cover could be exposed for convenience. |
@NSeydoux It wouldn't be too complex, except that it involves choices that we can't make for the developer. Specifically, what do we do if a Resource does not have its own ACL? Do we create it for them, do we modify the Container's Resource, do we throw an error? (And if the latter, then the developer will still be forced to write code to discover and modify the right ACL...) |
Is it the developer's choice to make in the first place though ? As long as the obtained result is spec-compliant and doesn't have side-effects, should clients care where the ACLs are stored ? As you said in an earlier comment, it is likely that most resources have their own ACL document, so it would be technically in-spec, when setting resource-scpecific access for an agent, to
This is out of scope for the current PR, because it is a complex feature and we would have to discuss the implications of implementing it, but I'd be interested to know if this is something that we might eventually want to expose, or if it is of a level of abstraction that requires too many assumptions on the desirable behaviour. |
Yep, definitely something to think about, especially after we've seen what the Pod Manager team is going to do here. I've already added a ticket to at least copy over existing applicable rules, because I'm expecting at least that to be desired. This potential feature could build on that. |
c02266e
to
fc41fab
Compare
New feature description
Given an ACL LitDataset, this PR adds
setAgentResourceAccessModes()
andsetAgentDefaultAccessModes()
that take an object with access modes (Read, Append, Write and/or Control), and make sure that the given modes are granted for the agent as resource or default access, respectively, and that any existing agent-specific modes that are not given are revoked.Note that the approach is rather convoluted, though I'm not sure if there's a better way. Specifically, what these functions do:
It's somewhat convoluted but, assuming that the clean-up function is accurate, the only way that feels safe to me. Most of that work should also be re-usable when adding support for setting e.g. public or group access, in the future, which will run into the same concerns.
Checklist
index.ts
, if applicable.