2011/11/22 Bertrand Delacretaz <[email protected]>: > On Tue, Nov 22, 2011 at 4:39 PM, Carsten Ziegeler <[email protected]> > wrote: >> 2011/11/22 Vidar Ramdal <[email protected]>: >>>... I'm coming late to this party, but having read the thread I'm not sure >>> if the proposal is about a) specifying access control APIs to be >>> implemented by resource providers, or b) implement access control >>> logic independently from (on top of) resource providers.... > >> ...the idea is about b) - I agree that thinks like search might get a >> little bit...well...interesting :) Though if you use the Sling search, >> you get resources and they will go through the same check mechanism.... > > Can this be done with a service interface like this, or is there more to it? > > public interface ResourceAccessGate { > /** @return false if access to the supplied Resource is denied for > supplied request */ > boolean acceptResource(SlingHttpServletRequest request, Resource resource); > }
Something similar - though we won't pass a request object into the check just the resource (resources can be get without a request) and we need to think about how to handle create. Now, as indicated this is an RT :) I think we won't implement this in the next days (patches welcome of course), but as soon as we split the resource resolver from the jcr provider, things like these get even more interesting (and get easier to implement hopefully) Regards Carsten > > If that's what you mean, I'd be ok as long as we clearly indicate that > this is just an additional application-level access gate, not to be > confused with ACLs which are handled at the repository level. > > Just something like the ResourceDecorator that we already have (and > both will be called in the same places probably). > > -Bertrand > -- Carsten Ziegeler [email protected]
