On 30.10.2012, at 08:43, Mike Müller <[email protected]> wrote: >>> 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.
I am confused. You mentioned this: > 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. Who is "Sling" in this case? >> 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. Ok, didn't know that the ResourceDecorator is still about read only. Cheers, Alex
