Torgeir Veimo wrote:
I have to agree, having programmatically security is much more useful
in a lot of scenarios.
One example is when the security requirements changes. If you have a
lot of ACLs in a very large repository, it becomes a nightmare to change.
It would be very handy to be able to express permission in terms of
scripts, with an appropriate selector mechanism.
That sounds like an interesting idea. We could provide an AccessManager
implementation that uses something like the Sling servlet resolution
process to locate per-resource-type or per-path "AccessHandler". These
services would then make the authorization decisions for the types or
paths they control. This might make implementing access policies like
the one Vidar described much simpler (than implementing an AccessManager
or plugin from scratch), since you enforce the policy at the type level
rather than at the each instance node of that type.
For instance if I may have a need to restrict access to nodes under
paths "/user/username" to be visible only to the user named "username".
I can of course create an appropriate ACL every time I create a new node
under the /user path, but it would be simpler & more reliable to just
register a path-based AccessHandler that controls /user, and just checks
that current authenticated user = username taken from the path.
I realize the downside of this approach is that, unlike the default
Jackrabbit ACLs, these kinds of policies aren't persisted in the
repository (they'd essentially be persisted in the Felix framework
properties if the registration of AccessHandlers was handled like
servlets), however, that might be acceptable for many applications.
This approach also addresses something I've previously wondered about:
access to servlets that are registered by path (like
/system/sling/login). There doesn't appear to be any way to apply
access control to these paths currently?
WDYT?
Rory
