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
