jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-2982) Extend syntax of ACL glob restrictions for properties
Date Thu, 22 Sep 2011 14:04:27 GMT

    [ 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

        

Mime
View raw message