[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
[ https://issues.apache.org/jira/browse/JCR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113280#comment-13113280 ] Tobias Bocanegra commented on JCR-2982: --- > which of the above is it? all of them, this is the ACL > does your |* only apply to the properties of /content? yes. i think the check for an item would calculate the match path, eg: "/content|jcr:title" and then match against "/content|*" > 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, security >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
[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
[ https://issues.apache.org/jira/browse/JCR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113274#comment-13113274 ] angela commented on JCR-2982: - > the most common use case i've seen so far, is to deny all child nodes. so > this could be done with: probably you mean: deny all child items except for properties of the target node, right? in contrast, deny all child nodes could also be read as only allow reading all properties in the subtree. > allow jcr:read on /content > deny jcr:read on /content with /* (denies all child nodes + properties) > allow jcr:read on /content with "|*" (allows all properties) which of the above is it? does your |* only apply to the properties of /content? > 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, security >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
[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
[ https://issues.apache.org/jira/browse/JCR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112723#comment-13112723 ] Tobias Bocanegra commented on JCR-2982: --- > the last example would break backwards compatibility, yes. we don't need that. the most common use case i've seen so far, is to deny all child nodes. so this could be done with: allow jcr:read on /content deny jcr:read on /content with /* (denies all child nodes + properties) allow jcr:read on /content with "|*" (allows all properties > 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, security >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
[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
[ https://issues.apache.org/jira/browse/JCR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112596#comment-13112596 ] angela commented on JCR-2982: - > 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) the last example would break backwards compatibility, which i would rather try to avoid. the solution depends on the needs, i.e. whether or not it was sufficient to explicitly address properties. honestly, i doubt that... so i would result in: - wildcard for any-item - wildcard for nodes - wildcard for properties > if the type of an item can be easily transported to the ACL evaluation [...] currently the type of item is not transported to the ACL evaluation for those cases where the eval is done for a path (and not an itemID). to achieve this, we either have to change the method signature or alternatively extend the Path interface. > 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, security >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
[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
[ 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
[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
[ https://issues.apache.org/jira/browse/JCR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078644#comment-13078644 ] Tobias Bocanegra commented on JCR-2982: --- @andrew: The intent of this issue is to provide a syntax to distinct properties from child nodes in the restrictions. I still don't see how your solution would help here. > 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
[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
[ https://issues.apache.org/jira/browse/JCR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072002#comment-13072002 ] Andrew DePompa commented on JCR-2982: - I suppose I should also mention that this fix isn't necessarily limited to properties. Anything can be put on the right hand side of the "|/" and match exactly as it would previously. The only difference being the parent node would also match now. > 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
[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
[ https://issues.apache.org/jira/browse/JCR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071990#comment-13071990 ] Andrew DePompa commented on JCR-2982: - It would match the expression "/content(/jcr*)". The '|' character is stripped for matching purposes and essentially sets a flag that ensures "/content" will match the pattern as well as any children that normally would have matched. As I said, it's a simple solution that meets essentially this single use case without introducing serious code changes that would have broken the existing pattern matching. > 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
[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
[ https://issues.apache.org/jira/browse/JCR-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069734#comment-13069734 ] Tobias Bocanegra commented on JCR-2982: --- > allow jcr:read on /content with "|/jcr*" - will match /content as well as all > of its jcr properties and any of their children. "their" (==properties) children? so it translates to this regexp: "/content(|/jcr:.*)?" ,right? i don't really see the benefit, it just makes it more difficult to understand. > 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
[jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
[ 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
