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
