Hi all, Bertrand asked what user interface we could use to configure an access control provider. We could do some wiring based on an osgi property, if it exists, using an scr annotation on the resource provider to specify the service which implements the access control gate (if one is not provided, use the JCR acl). The SlingMainServlet would check for this and call the appropriate method (e.g. acceptResource or whatever).
This way, the access control provider can be reused by different resource providers and we can change it in the OSGi console if required. The actual implementation can take care of whether to accept read, write, modify, etc. WDYT? Sarwar On Tue, Nov 22, 2011 at 4:11 PM, Carsten Ziegeler <[email protected]>wrote: > 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] >
