[
https://issues.apache.org/jira/browse/SLING-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15327985#comment-15327985
]
Georg Henzler commented on SLING-5768:
--------------------------------------
[~rombert] Thanks for looking into this. I fixed your suggestions and made
further improvements:
* Got rid of the google guava dependency (the oak restrictions use it, but we
don't really need it)
* Fixed mvn structure (sling parent, scope provided)
* Improved path matching matching resource types in sub nodes, e.g.
myproj/mypagetype@jcr:content (will also update ticket description for that)
* Resource type inheritance is not supported by design at the moment. I think
it would require a cache of the resource type hierarchy (and listeners etc.) to
not degrade performance too much. Also, usually hierarchy should be not too
complicated and it is always possible to list all resource types of a
hierarchy. Can be considered for a later version.
* rep:slingResourceTypes is quite verbose, and a name clash with other
"resource types" is very unlikely, therefore I decided to got for the simpler
rep:resourceTypes (also in respect to next bullet)
* Introduced rep:resourceTypesWithChildren that matches all resource types
matches including all of their children (that's the best name I could think of,
using "inheritance" in the name would not be a good idea). I think this is
useful for all container types (think jcr:content or accordions).
* Added JUnit tests with decent coverage
> Introduce rep:slingResourceTypes as extension to Oak permission system
> ----------------------------------------------------------------------
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Georg Henzler
>
> Oak allows to extend its permissions management by using custom restrictions
> \[1], also the standard oak restrictions are based on this and are
> implemented in a fairly straight-forward way \[2] (example is for
> rep:ntNames).
> It would be nice to have sling level restrictions using sling properties in
> general. This issue is about introducing a restriction on resource types -
> the following should be possible:
> {code}
> - /content/mynode
> - rep:policy (rep:ACL)
> - allow (rep:GrantACE)
> + principalName (String) = "myAuthorizable"
> + rep:privileges (Name[]) = "rep:write"
> - rep:restrictions (rep:Restrictions)
> + rep:slingResourceTypes (String[]) =
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other
> resources under path /content/mynode would not have "rep:write" permissions.
> See github PR for a first simple implementation (adding a bundle
> org.apache.sling.sling-oak-restrictions to contributions, not sure if this is
> the best spot).
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
