You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Mike Müller <mi...@mysign.ch> on 2012/10/26 10:43:08 UTC
[DISCUSS] Proposal for a minimal access gate on resource level
Hi
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
- and of course should not harm performance. The service should be
decoupled from the ResourceProvider to make it easy to define an access
gate which applies to resources from different ResourceProvider services.
Actually this last point is important to make it very easy to use.
I propose a new service interface ResourceAccessGateService:
interface ResourceAccessGateService
{
enum GateResult { GRANTED, DENIED, NOTRESPONSIBLE };
GateResult canRead( Resource, authenticationInfo );
GateResult canCreate( absPathName, authenticationInfo );
GateResult canUpdate( Resource, authenticationInfo );
GateResult canDelete( Resource, authenticationInfo );
GateResult canExecute( Resource, authenticationInfo );
GateResult canReadValue( Resource, valueName, authenticationInfo );
GateResult canCreateValue( Resource, valueName, authenticationInfo );
GateResult canUpdateValue( Resource, valueName, authenticationInfo );
GateResult canDeleteValue( Resource, valueName, authenticationInfo );
String sanitizeQuery( query, language, authenticationInfo ) throws
AccessGateException;
/* for convenience (and performance) */
boolean hasReadRestrictions( authenticationInfo );
boolean hasCreateRestrictions( authenticationInfo );
boolean hasUpdateRestrictions( authenticationInfo );
boolean hasDeleteRestrictions( authenticationInfo );
boolean hasExecuteRestrictions( authenticationInfo );
boolean canReadAllValues( Resource, authenticationInfo );
boolean canCreateAllValues( Resource, authenticationInfo );
boolean canUpdateAllValues( Resource, authenticationInfo );
boolean canDeleteAllValues( Resource, authenticationInfo );
}
Implementations of this service interface must be registered like
ResourceProvider with a path (like provider.roots). If different
ResourceAccessGateService services match a path, not only the
ResourceAccessGateService with the longest path should be called, but all
of them, that's in contrast to the ResourceProvider, but in this case more
logical (and secure!).
service properties:
path: regexp to define on which paths the service should be called
(default .*)
operations: set of operations on which the service should be called
("read,create,update,delete", default all of them)
finaloperations: set of operations on which the service answer is final an
no other service should be called (default none of them)
Okay, how should it work: First of all, if there's no registered
ResourceAccessGateService, nothing changes.
If one ore more ResourceAccessGateServices are registered Sling takes them
in account as follows:
Sling registers a ResourceDecorator and wraps with that service all
resources into a AccessGateResourceWrapper.
In general:
All servcies are called in the order of the service ranking. If one
service defines its answer as "final" (service property finaloperations),
then Sling takes the answer of this service and no other service is called
despite the service returns NOTRESPONSIBLE.
For READ:
After resolving and getting a resource from the ResourceProvider all
matching ResourceAccessGateService are called (canRead) in the order of
the service ranking and the resource only will be returned if one services
return GRANTED, otherwise a NonExistingResource is returned. This also
applies to findResources and queryResources. And yes in this case the
number of returned results can differ dependent on the implementations of
the ResourceAccessGateService. I don't think that's a big issue and users
of the ResourceAccessGateService have to be aware of this.
If there's a query to find resources, first of all the resource resolver
calls method sanitizeQuery on all ResourceAccessGateServices (because
there's no matching path). The ResourceAccessGateService either returns a
sanitized query (or the original query if everything is fine) or an
AccessGateException if the query is not allowed or illegal.
For UPDATE:
AccessGateResourceWrapper overwrites adaptTo an returns instead a
ModifiableValueMap (if requested) a ModifiableValueMapWrapper. If the
resource can't be modified (all ResourceAccessGateService#canUpdate
returns
DENIED) an AccessGateException will be throwed. The
ModifiableValueMapWrapper overwrites the methods put, putAll, remove and
clear and calls the appropriate methods (canUpdateValue and
canDeleteValue) on the registered ResourceAccessGateServices. The first
check will always be a call to canUpdateAllValues/canDeleteAllValues, if
this method returns true (from one service at least), no further call to
canUpdateValue/canDeleteValue has to be made. An implementation which does
not care about access to values is not slowed down. That's why this
additional (convenience) methods are important as well.
For CREATE:
This case is easy to implement: On ResourceResolver#create we call
ResourceAccessGateService#canCreateAllResources, if one returns GRANTED,
we
do nothing else. Otherwise we return an AccessGateResourceWrapper which is
aware, that the resource is just created. As long as the resource is not
committed (through ResourceResolver#commit) the returned
ModifiableValueMap (which is also aware of the "just created" through a
"pointer" to the AccessGateResourceWrapper) does call the appropriate
canCreateAllValues/canCreateValue. After calling commit the state "just
created" on the AccessGateResourceWrapper will be erased and therefore the
appropriate canUpdate methods will be called on the
ResourceAccessGateService.
For DELETE:
ResourceResolver#delete will take care to call the canDelete methods on
all matching ResourceAccessGateService. If one service returns GRANTED the
resource can be deleted.
Alternatively, to make the interface more flexible, we could combine the
canXXX() methods in a method named hasPermission with a parameter
"operation" as String.
So WDYT?
best regards
Mike
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 26.10.2012, at 10:43, Mike Müller <mi...@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
I think it might make sense for Resource implementations that don't have their own access control mechanism. If you already have one (like with JCR), it shouldn't be used/promoted, as that would just create confusion (why can't I configure this hard-coded rule etc.).
So if there is a need for that, I'd look for not adding this service to the sling resource core but allow it to be implemented in some kind of a wrapping resource provider, which you could hook in like any other resource provider. Becauser then people will get the idea to use it together with e.g. JCR ACLs and run into problems later which then fall back onto sling etc.
Cheers,
Alex
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Carsten Ziegeler <cz...@apache.org>.
I like this proposal as it is really generic and allows for some very
interesting use cases like denying access to resources for a given
time or allowing only access if the user has paid for the content or
whatever :)
And it's totally transparent and doesn't need any changes to the core.
As we're about to finalize the API release, I think we should try to
get this in as well. Could you maybe come up with a patch implementing
this?
I'm not 100% sure on the names and if we should have a fixed set of
methods or rather a more generic approach where the action (read,
write, execute...) is passed as a string (or enum). But I think we can
flesh this out easily.
Regards
Carsten
2012/10/26 Mike Müller <mi...@mysign.ch>:
> Hi
>
> 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
> - and of course should not harm performance. The service should be
> decoupled from the ResourceProvider to make it easy to define an access
> gate which applies to resources from different ResourceProvider services.
> Actually this last point is important to make it very easy to use.
>
> I propose a new service interface ResourceAccessGateService:
>
> interface ResourceAccessGateService
> {
> enum GateResult { GRANTED, DENIED, NOTRESPONSIBLE };
>
> GateResult canRead( Resource, authenticationInfo );
> GateResult canCreate( absPathName, authenticationInfo );
> GateResult canUpdate( Resource, authenticationInfo );
> GateResult canDelete( Resource, authenticationInfo );
> GateResult canExecute( Resource, authenticationInfo );
>
> GateResult canReadValue( Resource, valueName, authenticationInfo );
> GateResult canCreateValue( Resource, valueName, authenticationInfo );
> GateResult canUpdateValue( Resource, valueName, authenticationInfo );
> GateResult canDeleteValue( Resource, valueName, authenticationInfo );
>
> String sanitizeQuery( query, language, authenticationInfo ) throws
> AccessGateException;
>
> /* for convenience (and performance) */
> boolean hasReadRestrictions( authenticationInfo );
> boolean hasCreateRestrictions( authenticationInfo );
> boolean hasUpdateRestrictions( authenticationInfo );
> boolean hasDeleteRestrictions( authenticationInfo );
> boolean hasExecuteRestrictions( authenticationInfo );
>
> boolean canReadAllValues( Resource, authenticationInfo );
> boolean canCreateAllValues( Resource, authenticationInfo );
> boolean canUpdateAllValues( Resource, authenticationInfo );
> boolean canDeleteAllValues( Resource, authenticationInfo );
> }
>
> Implementations of this service interface must be registered like
> ResourceProvider with a path (like provider.roots). If different
> ResourceAccessGateService services match a path, not only the
> ResourceAccessGateService with the longest path should be called, but all
> of them, that's in contrast to the ResourceProvider, but in this case more
> logical (and secure!).
>
> service properties:
> path: regexp to define on which paths the service should be called
> (default .*)
> operations: set of operations on which the service should be called
> ("read,create,update,delete", default all of them)
> finaloperations: set of operations on which the service answer is final an
> no other service should be called (default none of them)
>
> Okay, how should it work: First of all, if there's no registered
> ResourceAccessGateService, nothing changes.
> If one ore more ResourceAccessGateServices are registered Sling takes them
> in account as follows:
>
> Sling registers a ResourceDecorator and wraps with that service all
> resources into a AccessGateResourceWrapper.
>
> In general:
> All servcies are called in the order of the service ranking. If one
> service defines its answer as "final" (service property finaloperations),
> then Sling takes the answer of this service and no other service is called
> despite the service returns NOTRESPONSIBLE.
>
> For READ:
> After resolving and getting a resource from the ResourceProvider all
> matching ResourceAccessGateService are called (canRead) in the order of
> the service ranking and the resource only will be returned if one services
> return GRANTED, otherwise a NonExistingResource is returned. This also
> applies to findResources and queryResources. And yes in this case the
> number of returned results can differ dependent on the implementations of
> the ResourceAccessGateService. I don't think that's a big issue and users
> of the ResourceAccessGateService have to be aware of this.
> If there's a query to find resources, first of all the resource resolver
> calls method sanitizeQuery on all ResourceAccessGateServices (because
> there's no matching path). The ResourceAccessGateService either returns a
> sanitized query (or the original query if everything is fine) or an
> AccessGateException if the query is not allowed or illegal.
>
> For UPDATE:
> AccessGateResourceWrapper overwrites adaptTo an returns instead a
> ModifiableValueMap (if requested) a ModifiableValueMapWrapper. If the
> resource can't be modified (all ResourceAccessGateService#canUpdate
> returns
> DENIED) an AccessGateException will be throwed. The
> ModifiableValueMapWrapper overwrites the methods put, putAll, remove and
> clear and calls the appropriate methods (canUpdateValue and
> canDeleteValue) on the registered ResourceAccessGateServices. The first
> check will always be a call to canUpdateAllValues/canDeleteAllValues, if
> this method returns true (from one service at least), no further call to
> canUpdateValue/canDeleteValue has to be made. An implementation which does
> not care about access to values is not slowed down. That's why this
> additional (convenience) methods are important as well.
>
> For CREATE:
> This case is easy to implement: On ResourceResolver#create we call
> ResourceAccessGateService#canCreateAllResources, if one returns GRANTED,
> we
> do nothing else. Otherwise we return an AccessGateResourceWrapper which is
> aware, that the resource is just created. As long as the resource is not
> committed (through ResourceResolver#commit) the returned
> ModifiableValueMap (which is also aware of the "just created" through a
> "pointer" to the AccessGateResourceWrapper) does call the appropriate
> canCreateAllValues/canCreateValue. After calling commit the state "just
> created" on the AccessGateResourceWrapper will be erased and therefore the
> appropriate canUpdate methods will be called on the
> ResourceAccessGateService.
>
> For DELETE:
> ResourceResolver#delete will take care to call the canDelete methods on
> all matching ResourceAccessGateService. If one service returns GRANTED the
> resource can be deleted.
>
> Alternatively, to make the interface more flexible, we could combine the
> canXXX() methods in a method named hasPermission with a parameter
> "operation" as String.
>
> So WDYT?
>
> best regards
> Mike
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Carsten Ziegeler <cz...@apache.org>.
2012/10/29 Alexander Klimetschek <ak...@adobe.com>:
> On 29.10.2012, at 18:02, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> And it's totally transparent and doesn't need any changes to the core.
>
> Depends on what you define as "core". The proposal definitely mentions a change to the resource resolver core.
No, the resource resolver does not need any change - it can be done by
a resource decorator alone.
Carsten
>
> On 26.10.2012, at 10:43, Mike Müller <mi...@mysign.ch> wrote:
>
>> Okay, how should it work: First of all, if there's no registered
>> ResourceAccessGateService, nothing changes.
>> If one ore more ResourceAccessGateServices are registered Sling takes them
>> in account as follows:
>>
>> Sling registers a ResourceDecorator and wraps with that service all
>> resources into a AccessGateResourceWrapper.
>
> Couldn't a custom ResourceDecorator do this without any changes to the core resource bundles?
>
> Cheers,
> Alex
--
Carsten Ziegeler
cziegeler@apache.org
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 30.10.2012, at 08:43, Mike Müller <mi...@mysign.ch> wrote:
>>> And it's totally transparent and doesn't need any changes to the core.
>>
>> Depends on what you define as "core". The proposal definitely mentions a change to
>> the resource resolver core.
>
> No existing API will be changed. The changes are only "under the hood". These changes
> only come to "life" if someone implements a ResourceAccessGateService. The proposal
> only suggest a new service interface which can be implemented by a user of sling or not.
> In the case of not using this service, nothing changes from an API-view.
I am confused. You mentioned this:
> First of all, if there's no registered
> ResourceAccessGateService, nothing changes.
> If one ore more ResourceAccessGateServices are registered Sling takes them
> in account as follows:
>
> Sling registers a ResourceDecorator and wraps with that service all
> resources into a AccessGateResourceWrapper.
Who is "Sling" in this case?
>> Couldn't a custom ResourceDecorator do this without any changes to the core resource
>> bundles?
>
> A custom ResourceDecorator can not do the same job. There are different issues.
> You can't write a ResourceDecorator only for a specific path, so to restrict access
> for resources under /my/resources/only-during-day/ you have to write a ResourceDecorator
> which wraps all resources from every path, which is a lot of overhead. With the
> proposed ResourceAccessGateService only resources with restrictions will be wrapped.
> Finally the proposal is about to let the user define restrictions for all CRUD operations,
> not only read.
Ok, didn't know that the ResourceDecorator is still about read only.
Cheers,
Alex
RE: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Mike Müller <mi...@mysign.ch>.
> > And it's totally transparent and doesn't need any changes to the core.
>
> Depends on what you define as "core". The proposal definitely mentions a change to
> the resource resolver core.
No existing API will be changed. The changes are only "under the hood". These changes
only come to "life" if someone implements a ResourceAccessGateService. The proposal
only suggest a new service interface which can be implemented by a user of sling or not.
In the case of not using this service, nothing changes from an API-view.
> On 26.10.2012, at 10:43, Mike Müller <mi...@mysign.ch> wrote:
>
> > Okay, how should it work: First of all, if there's no registered
> > ResourceAccessGateService, nothing changes.
> > If one ore more ResourceAccessGateServices are registered Sling takes them
> > in account as follows:
> >
> > Sling registers a ResourceDecorator and wraps with that service all
> > resources into a AccessGateResourceWrapper.
>
> Couldn't a custom ResourceDecorator do this without any changes to the core resource
> bundles?
A custom ResourceDecorator can not do the same job. There are different issues.
You can't write a ResourceDecorator only for a specific path, so to restrict access
for resources under /my/resources/only-during-day/ you have to write a ResourceDecorator
which wraps all resources from every path, which is a lot of overhead. With the
proposed ResourceAccessGateService only resources with restrictions will be wrapped.
Finally the proposal is about to let the user define restrictions for all CRUD operations,
not only read.
best regards
mike
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 29.10.2012, at 18:02, Carsten Ziegeler <cz...@apache.org> wrote:
> And it's totally transparent and doesn't need any changes to the core.
Depends on what you define as "core". The proposal definitely mentions a change to the resource resolver core.
On 26.10.2012, at 10:43, Mike Müller <mi...@mysign.ch> wrote:
> Okay, how should it work: First of all, if there's no registered
> ResourceAccessGateService, nothing changes.
> If one ore more ResourceAccessGateServices are registered Sling takes them
> in account as follows:
>
> Sling registers a ResourceDecorator and wraps with that service all
> resources into a AccessGateResourceWrapper.
Couldn't a custom ResourceDecorator do this without any changes to the core resource bundles?
Cheers,
Alex
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Carsten Ziegeler <cz...@apache.org>.
2012/10/30 Bertrand Delacretaz <bd...@apache.org>:
>> ...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 :)...
>
> Of course, but some consistency wouldn't hurt either, I don't see what
> makes the multiple methods better than the single method + permission
> name, and we already have that latter pattern in our codebase.
It's slower as it requires checking of the permission check :)
More serious, a string is open, it allows for typos (even if we
provide constants) and unexpected values which you also have to check
in your implementation. So instead of a serious of "if permission is
this" and "else throw/do nothing", separate methods make it imho
easier to use and implement.
But I don't really have a strong preference and would leave it up to
Mike providing the patch :)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Oct 30, 2012 at 10:59 AM, Carsten Ziegeler <cz...@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...
Thinking that no new types of permissions will come up is unrealistic
IMO. Moving a resource to a different path, changing a resource's
owner...back to Mike's changing the"no access between 8AM and 5PM"
access rule can also very well be a permission type. But I agree that
this would require handling the "unknown permission type" case.
> ...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 :)...
Of course, but some consistency wouldn't hurt either, I don't see what
makes the multiple methods better than the single method + permission
name, and we already have that latter pattern in our codebase.
-Bertrand
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Carsten Ziegeler <cz...@apache.org>.
2012/10/30 Ian Boston <ie...@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 <ie...@tfd.co.uk>:
>>> On 30 October 2012 20:18, Bertrand Delacretaz <bd...@apache.org> wrote:
>>>> Hi,
>>>>
>>>> On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller <mi...@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
>> cziegeler@apache.org
--
Carsten Ziegeler
cziegeler@apache.org
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Ian Boston <ie...@tfd.co.uk>.
On 30 October 2012 20:59, Carsten Ziegeler <cz...@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 <ie...@tfd.co.uk>:
>> On 30 October 2012 20:18, Bertrand Delacretaz <bd...@apache.org> wrote:
>>> Hi,
>>>
>>> On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller <mi...@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
> cziegeler@apache.org
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <ie...@tfd.co.uk>:
> On 30 October 2012 20:18, Bertrand Delacretaz <bd...@apache.org> wrote:
>> Hi,
>>
>> On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller <mi...@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
cziegeler@apache.org
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Ian Boston <ie...@tfd.co.uk>.
On 30 October 2012 20:18, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller <mi...@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
Re: [DISCUSS] Proposal for a minimal access gate on resource level
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller <mi...@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).
-Bertrand