Hi Carsten, On Fri, Nov 11, 2011 at 7:29 PM, Carsten Ziegeler <[email protected]> wrote: > 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!
+1 > > 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. > I like the general design here. I suspect this also means we're going to have to expand the ResourceResolver API a bit to include not just the userId but some notion of groups as both an ACLAwareResourceProvider and the ResourceAccessController will likely want to make access control decisions based on more that the userId. Perhaps we can use UserAdmin for this. > 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. Playing devil's advocate here... why is this a problem? This seems like it might be a good thing in some cases. Justin > > WDYT? > > Regads > Carsten > -- > Carsten Ziegeler > [email protected] >
