[
https://issues.apache.org/jira/browse/JCR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079538#comment-13079538
]
Andrew DePompa commented on JCR-2982:
-------------------------------------
I think you're right. I just latched onto the single example provided and fixed
a problem I've been having that is similar but not quite the same. I've also
noticed over the past few days that it may also be doable with existing
functionality.
> 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