Hello Please accept my 2.3 cents to this discussion:
I really agree with Angela and Bertrand on this one. Something that could be called AccessGate is clearly a security mechanism, and should thus be designed with single point of access in mind. Having ACL evaluations scattered among the code-base makes it harder to configure (and thus easier to make mistakes), and increases the overall attack surface. To me Sling is not the right layer for such a feature, IMHO it should be implemented on repository level by extending Jackrabbit's ACL evaluation if time-based access control is really needed. This is also an example of how this feature would weaken security. In order to allow access to a resource within a certain time-frame, you will have to open access completely on repository level, so the whole access control would depend on the Sling layer, and we introduce a bunch of new attack possibilities, and unnecessarily complicate the threat model. I think a ResourceResolverDecorator might be useful in some cases. But having access control features in sling core just feels wrong to me. Best greetings Lars On 03/06/2013 11:23 AM, Bertrand Delacretaz wrote: > On Wed, Mar 6, 2013 at 11:03 AM, Carsten Ziegeler <[email protected]> > wrote: >> ...this would mean, we trust people implementing >> ResourceResolverDecorator, but we don't trust them implementing >> ResourceAccessGates.... > > I see your point...I guess it's very subjective factors here, I prefer > ResourceResolverDecorator to ResourceAccessGate although both can > potentially be abused (like many of our extension points). > > Let's see what others think. > > -Bertrand >
