Hi, On Wed, Mar 6, 2013 at 8:40 AM, Carsten Ziegeler <[email protected]> wrote: > ...Then we have the issue of whether to put the support for this into the > resource resolver bundle or not - while I see the point for keeping it > separate, I think it is a central piece of the resource resolving > infrastructure, so it's not really different from that pov than the > crud stuff we added or maybe vanity urls...
I disagree - the big difference is that the access gate can easily be seen as a security mechanism, which blurs the overall security concept and that's a very bad thing. I know Mike has stated several time that the access gate should not be seen as a security feature - if that's implemented in a separate bundle in contrib, people are much more likely to see it as that, whereas having that in a core bundle like the resource resolver makes it much easier to confuse with a security feature. > ...We never even talked about > putting this stuff into a separate bundle... Now that we see the code, several of us think it should. It doesn't matter to me whether we discussed that before or not (and it shows that code speaks louder than words). > ....I really don't want to > open doors for everyone to overload a resource resolver (like with the > customizer proposal).... > ...Finally, although this feature is optional and has no impact if not > used, there are valid concerns that this might be easily abused. But > we can't prevent anyone from abusing stuff and we already have various > places where people do funny things... Those two statements are somewhat contradictory. I'm strongly in favor of the ResourceResolverDecorator option that Mike suggests in his latest SLING-2698 comment, where the access gate stuff can go in a separate contrib bundle, because: a) That's consistent with how we do things elsewhere (ResourceDecorator - which can also be abused in fun ways) b) Having the access gate in a contrib bundle makes it clear that it's not the mainstream way to use sling c) The resource resolver bundle, which is core, stays clean and minimal Thinking about it, this is quite similar to the PathBasedResourceDecorator from the samples/path-based-rtp bundle, which generates resource types based on paths. That's not a mainstream way of using Sling, it's useful sometimes, and to implement it we added the ResourceDecorator to avoid polluting the Sling core with that optional stuff. Lots of parallels which speak for the ResourceResolverDecorator option. -Bertrand
