> Sorry for asking a stupid question, but why would a ResourceProvider > that delivered resources subject to security, not implement it that > security and cover the use cases required as a part of its > implementation ? > > 1 Allowing insecure ResourceProviders to exist with the intention of > decorating them feels to be like a dangerous path to take. If they are > used without decoration they become unsafe. > > 2 If the use case is an additional layer of security ontop of a secure > resource provider (eg a rules based ACL), then I can see that there > might be a genuine need, but I have to ask why isn't the security part > of the resource provider itself because its too easy to circumvent > when resources are navigable.
The use case is different: We will (or should) have ResourceProviders for non ACL aware storages like MongoDB, Cassandra (or like Bertrand mentioned SolR) etc. in the future. I don't think it would make sense to implement ACLs or some other security mechanism in each of these ResourceProviders. And not using them because they do not have a ACL mechanism is maybe not the right way to go. Sling should not be only a JCR frontend in the future, that's why I think we should be able to deal with this new sort of non ACL aware ResourceProviders and at this point the ResourceProviderDecorator or ResourceAccessGate (or whatever) comes in. It is not designed to be used as a ACL layer on top of JCR, there we don't need it. best regards mike
