[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties

["Andrew DePompa (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069697#comment-13069697 ] 

Andrew DePompa commented on JCR-2982:
-------------------------------------

I've written a fairly simple solution that addresses this use case that I've been using locally for a while now. I started with Tobias's suggestion to use the '|' character but instead of using it to indicate that what follows is a property it now means to include "this" node (this being the node that the ACE is being set on). Thus, the pattern matching remains basically the same but '|' acts as a flag when included at the beginning of the pattern that returns true if the exact node path is checked.

For example: 
allow jcr:read on /content with "|/jcr*" - will match /content as well as all of its jcr properties and any of their children.

If this seems like a reasonable solution, I'd be willing to submit it for review.

> Extend syntax of ACL glob restrictions for properties
> -----------------------------------------------------
>
>                 Key: JCR-2982
>                 URL: https://issues.apache.org/jira/browse/JCR-2982
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>    Affects Versions: 2.3.0
>            Reporter: Tobias Bocanegra
>             Fix For: 2.3.0
>
>
> the current glob restrictions on resource based ACL simply adds the glob pattern to the path of the defining node. the resulting pattern is then used to match against the path of the item to be evaluated.
> eg: jcr:read on /content with /foo* will match all items having a path that matches "/content/foo*" including the properties of /content starting with foo'.
> A common usecase for using ACL restrictions is to allow read access to a node and it's properties, but generally deny it for it's child nodes: 
>   allow jcr:read on /content
>   deny jcr:read on /content with /*
> this would be easy, but as mentioned above, would also include the node's properties, thus preventing them from being read.
> Suggest to modify the pattern matching by explicitly address properties differently by using a special prefix, like "|" (an illegal jcr char).
> eg:
>   allow jcr:read on /content
>   deny jcr:read on /content with "|jcr:*" (denies all properties starting with "jcr:*")
>   deny jcr:read on /content with /* (denies all child nodes)
> if the type of an item can be easily transported to the ACL evaluation, then composing the path to be matched is simple:
> eg:
>  if the item is a property /content/jcr:title, then the match-path is: /content|jcr:title so would not match /content/*, but /content|jcr:* of the example above.
> (Another option would be to support xpath restrictions - but this might be not performant enough)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira