Hi Julian, I don't think I understand what you are suggesting here. Can you elaborate on what the code path would be in the case, for example, of a Bundle Resource Provider? If a bundle provides resources under, say, /mybundle, where would the ACL live and who would be responsible for evaluating it?
I feel like I'm missing something obvious, so please bear with me :) Thanks, Justin On Sat, Nov 12, 2011 at 9:16 AM, Julian Sedding <[email protected]> wrote: > Hi Carsten > > Interesting idea. Having access control handled by services allows > implementing arbitrary access control logic, which I would welcome. In > my experience, it's often difficult to express access control logic in > a declarative manner. > > I think we could further simplify the approach you describe. Leave the > ResourceProvider interface as it is and don't introduce an > ACLAwareResourceProvider interface. Instead have the JCR > ResourceProvider also implement ResourceAccessController. This > simplifies the design, while allowing to expose the same logic. > Additionally, it adds the possibility to layer additional access > control on top of Jackrabbit ACLs, thus allowing to combine the best > of both worlds (access control logic implemented in java + > Jackrabbit's declarative ACLs). > > Thoughts? > > Regards > Julian > > > On Sat, Nov 12, 2011 at 4:29 AM, 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! >> >> 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] >> >
