This idea is about to provide a general approach for resource checking. Noone prevents you from doing a virtual tree in the jcr repository to check access of resources provided by other providers. But that's an implementation detail which I don't want to require upfront!
Think in terms of our resource abstraction - so far I don't see the need to define any API to set/change/query these additional checks within Sling. Regards Carsten 2011/11/22 Bertrand Delacretaz <[email protected]>: > On Tue, Nov 22, 2011 at 1:45 PM, Alexander Klimetschek > <[email protected]> wrote: >> ...Personally I think it is much better to put such additional ACL >> implementations into the JCR (e.g. a custom Jackrabbit access control >> provider). The problem is that anytime your code is using JCR (such as for >> complex operations not possible through the simple resource API) your >> sling-based access control won't be used at all.... > > Right...adding an ACL layer that's not based on JCR might generate a > lot of confusion IMO. > > And where are we going to implement user/RESTful interfaces for > defining such ACLs? New additional APIs and UIs? > > To keep things simple I'd suggest using a "shadow resource tree" in > JCR if we need to define access control for ResourceResolvers which > are not JCR: have the /SLING-ACL/resolvers/com.example.bar/foo > repository node define ACL for resource /foo provided by provider > com.example.bar, for example. > > That doesn't solve Mike's time-based ACLs, but I'd handle those > separately at the application level (or in a Filter) anyway. Having > ACLs that depend on something else than the current request's > credentials might break too many existing semantics (caching etc). > > -Bertrand > -- Carsten Ziegeler [email protected]
