Hi, On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller <mike...@mysign.ch> wrote: > ...The main goal of this proposal is to provide a easy to use service in > Sling to restrict (or grant) access to resources for special use cases > (like giving access to some resources only between 8am and 5pm). The > service should be very lightweight and should NOT be a replacement of ACLs...
You have my bet that people *will* use this service as a replacement for ACLs, and reinvent a few wheels in the process ;-) In the end, between this and the CRUD resource API changes we are moving to two flavors of Sling: JCR-based, where the repository fully handles such things, and non-JCR, where you need to implement your own ResourceAccessGates and other niceties that JCR provides. I'm not against that, as long as it's a conscious decision and as long as we're clear about best practices in either case. > ...I propose a new service interface ResourceAccessGateService... I'd call that just ResourceAccessGate. > enum GateResult { GRANTED, DENIED, NOTRESPONSIBLE }; DONTCARE instead of NOTRESPONSIBLE maybe? > ...Alternatively, to make the interface more flexible, we could combine the > canXXX() methods in a method named hasPermission with a parameter > "operation" as String.... I'd much prefer that, if this model can be closer to JCR's Session.checkPermission(String absPath, String actions) that's helpful IMO. (which makes me think that a new Resource.checkPermission method might be more in line with Sling's resource-centric view on things). -Bertrand