You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2013/05/07 19:07:16 UTC
[jira] [Commented] (OAK-774) Calculate readstatus
[ https://issues.apache.org/jira/browse/OAK-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651064#comment-13651064 ]
angela commented on OAK-774:
----------------------------
cool, thanks a lot for the patch... very much appreciated as this
is really a tricky piece! in general separating out the read status calculation
from the regular permission eval makes a lot more sense IMO.
some additional comments:
- that initial part doesn't cover readability of ac content, right?
could that be the reason for failing tests (there is one specific
for the globbing restriction)...
- after the calculation i would first test if there is a entry in the
map for the specified path before iterating over the keys.
- regarding #getReadStatus: no sure, if i properly get that... from a
first glance i would suspect that there is an issue with the DENY_NODES
at line 241. furthermore, i somewhat get the feeling that the different
methods to calculate the final status have a lot of similar code...
that sounds like a candidate for being merged...
maybe we need a way to add/subtract readstatus (see privilegebits for
a similar concept) in order to simplify it? what do you think?
- ReadStatusEntryPredicate: the apply call returns false if the other entry
is created for the same path... how do you then "add" addition permission
if entry1 on path /a grants read_nodes and entry2 on path /a grants read_properties?
i guess i am missing a piece here...
- As far as the restrictions are concerned:
If they match that path of the permission entry this isn't a guarantee that
they also match to all child items... that looks a bit suspicious in the
current implementation (or maybe i misread it). imo we can either
> have always ALLOW/DENY_THIS if there is a restriction present
> extend the RestrictionPattern interface to allow for more fine grained
information (basically delegating the responsibility to the impl)
> add specific code for known restrictions (for example the globpattern "" or "/*").
> Calculate readstatus
> --------------------
>
> Key: OAK-774
> URL: https://issues.apache.org/jira/browse/OAK-774
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, jcr
> Reporter: angela
> Assignee: angela
> Attachments: OAK-774-patch.txt, OAK-774-test-patch.txt, OAK-774-test-patch.txt
>
>
> this includes 2 major steps:
> - clarify meaning of ReadStatus.*_ALL in terms of reading access control
> content (and possibly extend the set of existing status)
> - implement calculation of read status in compiled permission impl
>
> the 2 things together will allow us to improve performance within the
> SecureNodeState for those trees where a given user has full access or
> at least full access to non-ac items.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira