Created AuthorizationHandler interface. #7
Conversation
| * @param objectType | ||
| * @return List of ACL objects for the objectType | ||
| */ | ||
| List<WebACAuthorization> getAuthorizationforType(final RDF objectType); |
There was a problem hiding this comment.
Does the WebACAuthorization class exist?
There was a problem hiding this comment.
That's the interface I am building. So it will or some implementation of it at least.
mohideen
changed the title
| * @param aclPath Path of acl to get authorizations. | ||
| * @param resourcePath Path of the resource requested by user. (ACL: accessTo) | ||
| * @param objectTypes rdf:type values of the resource. (ACL: accessToClass) | ||
| * @param agent (user or group) (ACL: agent) |
There was a problem hiding this comment.
How will you determine whether this is an agent (or agents) and therefore use acl:agent or a group (or groups) and therefore use acl:agentClass?
There was a problem hiding this comment.
I think we decided to use acl:agent for both users and groups.
There was a problem hiding this comment.
Yes, but we also probably need to keep the userId separate from the groupIds... in order to facilitate prioritization in determining the effective Authorization.
There was a problem hiding this comment.
Would there be any distinction between an user and a group in the acl:Authorization object?
There was a problem hiding this comment.
currently they are retrieved by use of different methods getAgents and getAgentClasses.
_edit_
but that was assuming they would be stored in the Authorization differently, if they are all in the ACL with acl:agent I should probably update that.
The difference will be that an agent is a string username, and an agentClass is a URI that resolves to a list of agents
There was a problem hiding this comment.
@whikloj, acl:agentClass is very different from our String-based notion of "groups".
There was a problem hiding this comment.
Sorry @awoods, I must have dozed off. So we are using Strings for both agents and agentClasses? Then I also am wondering how I can tell if a
<> acl:agent "Jim"
is an username or group called "Jim"?
There was a problem hiding this comment.
@whikloj, I don't think it matters. What matters is if "Jim" is the requesting user's userId or one of their groupIds.
There was a problem hiding this comment.
Ok, then I am dumping the WebACAuthorization.getAgentClasses() as it will be irrelevant.
|
Just a point of clarification, are the add/replace/removeAuthorizations methods intended to be used for the editing of ACLs? |
|
Yes, to manage acl:Authorization nodes in a given ex:Acl. |
|
@mohideen I was under the impression that since we were making the acl:Authorization nodes LDP children under the ex:Acl container, that we would use the usual LDP methods for editing them (PUT to add and replace, DELETE to remove). In that case, do we need specialized methods in the AuthorizationHandler? |
|
I was thinking about these in the context of UI. We might not need these then. |
|
Agreed, @peichman-umd and @mohideen. We will likely be using straight LDP to update Authorizations, not object setters. |
|
@mohideen, can you clarify the different purposes of the two |
|
Wasn't sure if the delegate OR AuthorizationHandler will be implementing the logic for traversing up the tree to find if an ACL exists. |
|
First method assumes it happens in delegate, second assume in AuthHandler. We will only need one. |
|
I thought we just wanted the delegate to make the final decision with all relevant data, which puts it into the AuthHandler. But I don't know if we had a final decision on that. |
|
Like @acoburn has mentioned, it would be ideal to keep jcr.Sessions (to the extent possible) from leaking outside of the Delegate. |
|
Ok, so the Delegate checks for the ex:hasAcl and then passes that resource to the AuthHandler. |
|
@whikloj, sounds good. |
| return null; | ||
| } | ||
|
|
||
| public Set<WebACAuthorization> getAuthorizations(FedoraResource resource, String agent) { |
There was a problem hiding this comment.
This method can be removed as well.
|
|
||
|
|
||
| /** | ||
| * Get authorizations that have both accessTo |
There was a problem hiding this comment.
Trying to understand this comment: "...that have both accessTo [and what?]"
|
I think this should be closed due to work being done @acoburn |
|
We can close this in favor of #8 |
No description provided.