Skip to content
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

Closed
wants to merge 2 commits into from
Closed

Implement support for acl:agentClass triples #40

wants to merge 2 commits into from

Conversation

acoburn
Copy link
Contributor

@acoburn acoburn commented Oct 29, 2015

final FedoraResource resource = nodeService.find(
internalSession, x.substring(FEDORA_INTERNAL_PREFIX.length()));
members.addAll(getFoafMembers(translator, resource));
} else if (x.startsWith(FOAF_NAMESPACE_VALUE)) {
Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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())
Copy link
Member

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?

@awoods
Copy link
Member

awoods commented Oct 30, 2015

Resolved with: 4871919

@awoods awoods closed this Oct 30, 2015
@acoburn acoburn deleted the fcrepo-1793 branch July 21, 2016 16:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants