On 30 October 2012 20:59, Carsten Ziegeler <cziege...@apache.org> wrote:
> 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.
true.
what about being able to check for a set of permissions in one go ?
>
> 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
