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
