2012/10/30 Ian Boston <i...@tfd.co.uk>: > what about being able to check for a set of permissions in one go ?
As far as the proposal goes, there is no need for this as usually always exactly one permission is checked. Carsten > >> >> 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. > > that works for me. > > Ian > >> >> 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 -- Carsten Ziegeler cziege...@apache.org