[
https://issues.apache.org/jira/browse/JCR-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-2842.
-------------------------
Resolution: Later
> Avoid excessive node access during ac evaluation (followup to JCR-2573)
> -----------------------------------------------------------------------
>
> Key: JCR-2842
> URL: https://issues.apache.org/jira/browse/JCR-2842
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core, security
> Reporter: angela
> Assignee: angela
>
> the resource-based access control management in JR currently requires a lot
> of read operations in order to collect the
> relevant access control entries (walking up the node hierarchy).
> this could be improved by various means such as e.g. :
> 1. define means to stop the entry collection if the required information is
> already found.
> 2. enhanced storage mechanism for access control content that allows to
> quickly determine all accesscontrolled ancestors.
> regarding 1)
> this could be achieved without major refactoring for
> AccessControlProvider#canRead that solely focusses on read permission. for any
> other permission evaluation this may require some additional refactoring as
> currently the complete set of permissions is calculated.
> regarding 2)
> we (david, michi, jukka and myself) had various discussions about this
> approach during the last couple of month. possible solutions
> brought up in initial brainstorming included modification on the persistence
> level as well as "highlevel" changes simply additing
> additional information to the ACL node. All approaches discussed so far would
> allow to determine and collect more easily the AC
> information effective at a given node in the hierarchy starting from a
> general "the evaluation mechanism knows about all ac content" to
> "a single acl knows the next parent-acl in the hierarchy"... these just to
> mention some ideas of our discussions.
> starting next year i will spent some time on this and create one (or several)
> prototype(s) in order to have something real to
> discuss about.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
