> From: Felix Meschberger [mailto:fmesc...@adobe.com] > > Okay, as far as I understand we've got the consensus of separating my > > access gate > > proposal from the Sling API. We should have something like a > ResourceAccessSecurity > > service in a extension bundle, > > I think we can keep the basic singleton service (you call it > ResourceAccessSecurity > now, right?) in the API and document it like this: > > * Expected to only be implemented once in the framework/application > (much like the OSGi LogService or Configuration Admin Service) > * ResourceProvider implementations are encouraged (or stronger) > to use this service for access control unless the underlying > storage already has it. > > > I think we don't loose the goal of bringing Sling > > forward to a frontend of resources from different providers than JCR without > > any security built in (like MongoDB, file provider, bundle provider etc.) > > with this > > new setup. If we go down this road I propose the following: > > > > Making a new bundle (extension) with a new service called > > ResourceAccessSecurity. > > +1 > > > Taking the ResourceAccessGate interface out of the Sling API but keeping it > > as > > a "access rule feeder" interface for the new ResourceAccessSecurity service. > > So the actual ResourceAccessSecurity service implementation bundle will > define its own > extensibility model, right ?
Yes, that's right, through the ResourceAccessGate interface. Best regards mike
