> > 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 <mike...@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
