On 06.03.2013, at 15:43, Mike Müller <[email protected]> wrote: > 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.
Could you elaborate a bit on your use case on what kind of resource providers you are using? And why does it have to be a special new interface and can't be a decorator or a resource provider? > 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 more the other way around: your case seems to be more specific, and we should not introduce that specific solution (that you feel comfortable with as you make sure you don't mix the responsibilities of layers) into the core sling resource handling. > 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. Sling is a web framework, about routing, servlet + script rendering etc. Defining ACL security is not it's business - this is the business of the resource backends. Just because many of those don't have any extensible security mechanisms or are used in a "admin-jdbc-connection" mode all the time and it looks easier to code high up in Sling is IMHO not a good argument to break Slings clear focus. Which is not JCR only, but clearly does expect some powerful infrastructure like JCR underneath. Cheers, Alex
