> 2011/11/22 Bertrand Delacretaz <[email protected]>: > > On Tue, Nov 22, 2011 at 2:17 PM, Carsten Ziegeler <[email protected]> > > wrote: > >> This idea is about to provide a general approach for resource > >> checking > >>... > >> Think in terms of our resource abstraction - so far I don't see the > >> need to define any API to set/change/query these additional checks > >> within Sling. > > > > But these restrictions on resource access will need to be defined > > somewhere, right? > > How do you see this? > > > I don't care :) We just provide the interface/hook to do that. If > you're using a repository then maybe the shadow tree is a good > approach. If you don't have a repo, you need something else. > In some cases, you might just want to check if the current user is > admin and allow things, or if the user is authenticated at all. Or you > want to query your LDAP. Or variations on the theme. > > We're providing a framework which should not prevent users from doing > their stuff - and as we see with Mike's case, there are valid use > cases. > > And even with doing the jcr shadow tree or something like on/off times > in the repository, with the provided interface you have a good way of > hooking this into the system :)
+1 It's not about avoiding JCR ACLs, it's more about to make the access controlling more flexible and independent from the JCR. But the feature should not prevent the user just to use JCR ACLs. So the extension is built only as a service interface to "intercept" the normal flow if needed. best regards mike
