Hi, Sorry, too, for being late at the party ...
I think we should * keep it simple * not try to duplicate existing stuff * ensure consistency Thus, I think the Sling Resource API should not impose another layer of access control checks to what is already implemented in ResourceProvider implementations. Rather, I think the Sling Resource API should just expose the same checks. Just like the JCR 1.0 Session.checkPermission method does. So I suggest, we extend the Resource API as follows: boolean ResourceResolver.hasPermission(String absPath, String action); boolean ResourceProvider.hasPermission(String absPath, String action); Applications may call the ResourceResolver.hasPermission method to check whether the given action is allowed on a (potential) resource at the given absolute path. The ResourceResolver implementation would then select the ResourceProvider services to call in the same way as they are selected already to implement the ResourceResolver.getResource(String) method. This allows delegation of the hasPermission implementation from the path-wise-best-matching provider to the root provider (generally JCR). In addition, we would define a set of actions use full in terms of Sling: cread, read, update , delete (aka CRUD) plus (maybe) execute (for calling scripts and servlets). The Sling Resource API explicitly does not state how access control is implemented and configured. This remains part of the ResourceProvider's implementation detail. Regards Felix Am 12.11.2011 um 04:29 schrieb Carsten Ziegeler: > We support different resource providers, JCR, bundle, file etc. but so > far only JCR implements access control based on the provided user. > This leads to problems when resources are provided for example from a > bundle or the file system as there is either no real ACL check is in > place. > I think we should change that! > > First, if a resource provider supports ACL checks like JCR it just > should declare this by using a new interface ACLAwareResourceProvider > (or any better name) which is just a marker interface. > If a resource is provided by provider which does not declare this, > well send the resource through a new service ResourceAccessControler > (or a better name) which either allows or denies the resource. We > could allow here several services which are asked in the order of > their service ranking until one of them provides a definite answer. If > none provides an answer, the resource is served - for compatibility. > > With this we should be able to easily hook on access control for such > providers not directly supporting it while staying compatible. > > Now, however there is a problem with the whole apprach - if a provider > is an ACLAwareResourceProvider we need to know internally if the > resource exists but the user is not allowed to access it, or if the > resource does not exist. Otherwise we potentially end up with a > resource at /somepath provided by provider A for user U1, and provided > by provider B for user U2 as user U2 is not allowed to access this > resource in provider A. > > WDYT? > > Regads > Carsten > -- > Carsten Ziegeler > [email protected]
