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
Implement support for acl:agentClass triples #40
Conversation
final FedoraResource resource = nodeService.find( | ||
internalSession, x.substring(FEDORA_INTERNAL_PREFIX.length())); | ||
members.addAll(getFoafMembers(translator, resource)); | ||
} else if (x.startsWith(FOAF_NAMESPACE_VALUE)) { |
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.
Where does this logic come from? Does it map into the "spec"?
https://www.w3.org/wiki/WebAccessControl
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 logic comes from the examples in the "spec". The W3C document provides two types of examples of acl:agentClass
:
- the first class of examples includes references to an
rdfs:Class
, e.g.<> acl:agentClass foaf:Agent .
(These do not require further dereferencing.) - the second class of examples include a URI that can be dereferenced. These can be divided into two groups -- those URIs that are local and those that are external. We decided to exclude external references for now, so the logic only follows local URIs.
This does raise a question about what constitutes a valid target for an acl:agentClass
resource. We could choose to also support ore:aggregates
, but for now foaf:member
seems sufficient, and so that's what has been implemented.
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.
Thanks, I see where the else if (x.startsWith(FOAF_NAMESPACE_VALUE))
comes from now; however, is this the logic we want? namely, to honor any term that happens to be in the foaf
namespace as an acl:agentClass
?
If we are just expecting foaf:Agent
, we should probably restrict the logic to that.
If we are expecting any rdf:type
that may define a category of agent, we should open the door wider.
But allowing any foaf
terms seems like an odd middle-ground.
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.
I agree, we should simply test for foaf:Agent
.
@@ -148,7 +153,8 @@ public void deleteRoles(final Node node) throws RepositoryException { | |||
authorizations.stream() | |||
.filter(x -> checkAccessTo.test(x) || checkAccessToClass.test(x)) | |||
.forEach(x -> { | |||
x.getAgents().stream() | |||
Stream.concat(x.getAgents().stream(), dereferenceAgentClasses(x.getAgentClasses()).stream()) |
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.
I may be confused, but you are doing the checkAccessToClass above this forEach. Would it still be required? Or is that to allow for string agentClasses?
Resolved with: 4871919 |
See: https://jira.duraspace.org/browse/FCREPO-1793