There are to main arguments which are repeatedly mentioned: First we should not duplicate ACLs in a Sling layer and the second that users of Sling can misunderstand the new service or abuse it.
For the first argument: One thing which was never taken in account is that Sling is not only a frontend for JCR (maybe in the old days this was the case). Sling has different resource providers beside the JCR provider like providers for files, bundles, servlets, etc. These providers come without any possibilities of restrictions. But we do provide them as extension bundles (not contrib!). Think of a sling application with different providers installed, say all registered somewhere under /mypath/... Now, how should it be easily managed to restrict access to all resources Under /mypath/... to be accessed only by logged in users or even better only from 8am to 5pm based on the time zone of the logged in user. Is the answer today to write the resource providers for files, bundles, servlets, etc. yourself. The ResourceAccessGate service would be an answer to that. It's not about JCR-ACLs or ResourceAccessGate and it doesn't weak any existing security rules, that's definitely not true. It is also not about having ACLs on different layers. It's just about to give an easy to use service to sling users which do not only rely on JCR alone or want to define a rule over different providers at a single place. For the second argument I do not have much sympathy: Only because some users could abuse or misunderstand the purpose of a specific service we should not stop to introduce reasonable new stuff. And as a side note: I personally think the very powerful adaptable feature (which I like) is much more abused than ResourceAccessGate ever could be... I think it's time to see Sling not only as JCR frontend. Why beeing afraid seeing Sling as what it is: as a frontend for different providers and therefore provide the tools to make that easy. I sometimes miss the declared intention to win some new users (which are all potential commiters) for sling. So whatever solution we can agree on for implementing ResourceAccessGate service, it shouldn't be something which takes place in a contrib bundle. Best regards mike
