hi jukka this is not quite true. as i will explain below.
first i would strongly recommend not to rely on the current implementation. if we have the requirement to evaluated permissions based on the path we may extend the permissionprovider which IMO is the key API for these cases; not the treepermissions. however, please be aware that one key feature of oak (compared to jackrabbit which only allowed permission evaluation by path) is that it always needs to be clear if the target for the permission evaluation is a node or a property. similarly, the restrictions may require the item being retrieved in order to perform the required evaluation (e.g. restricting access by node type). also the evaluation is obligated to respect the different types of items when it comes to read access. in other words: extending the the permissionprovider with something like isGranted(@Nonnull String treePath, @Nullable String propertyName, long permissions). will just be an optimization for those cases where full access is granted everywhere which can equally be determined by calling TreePermission#canReadAll on the root node. so, i would recommend to first explore if the method would not just serve the purpose. kind regards angela On 25/06/14 16:48, "Jukka Zitting" <[email protected]> wrote: >Hi, > >On Wed, Jun 25, 2014 at 10:16 AM, Thomas Mueller <[email protected]> >wrote: >> Yes, we would need to use a different access control API. The ability to >> check whether a session has access to a path/node/property, without >> actually loading the node from the storage backend. Maybe that API is >> already there? > >The TreePermission interface is the key API here, and the way we've >designed it requires loading the nodes being accessed (see the >getChildPermission method). The current implementation of the API >actually *doesn't* strictly require the loading of the underlying >nodes, so we might be able to refactor the API to better accommodate >such indexes. > >BR, > >Jukka Zitting
