I'm not sure about checkPermission with a String (or String[]). This would imho only make sense if we see that we will have more permissions in the future which I really don't see. And we don't need an extension here as each additional permission would require changes in the implementation to check those anyway.
So I would go with the separate methods - we could provide an abstract class which already implements all methods, so implementing would be just overwriting the required ones. I also don't see a need to do it in the same way as JCR does - we should do it what fits best in our resource api and what is the best way to cover the use cases :) Adding checks on the resource interface is problematic as this would require each and every resource provider to implement these methods - and this proposal is orthogonal so to speak to acl checks done by a resource provider. Carsten 2012/10/30 Ian Boston <i...@tfd.co.uk>: > On 30 October 2012 20:18, Bertrand Delacretaz <bdelacre...@apache.org> wrote: >> 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). > > I agree with the single method checkPermissions as its a lot less > overhead to those who have to implement, and the String actions allows > for extension being out of band. What about String[] actions to allow > one call to check many actions ? > > I am not certain about Resource.checkPermission (unless you mean a > static), as that assumes "read" is granted ? > > Ian > > >> >> -Bertrand -- Carsten Ziegeler cziege...@apache.org