Well, if locking is just about permission I do agree with ACLs being the right solution (the permission set on the node itself might be sufficient for that case) - if it is about businessconstraints that need to be fullfilled an ACL cannot solve this requirement[0]. This is why validation and so on should be performed first, I would think of a pipeline having a contract on each phase what can be done and what cannot be done, while a first phase might not write any data (even as transient changes) the next phase might be perform (transient) change, then the postoperations would be performed in a transient followed by another phase that might perform transient changes and/or stop the processing, followed by a last phase that is called after the resourceResolve has performed a commit().
This is purely about giving developers a contract on what they can and cannot do (and therefore what they can expect 3rd party code to do) at a specific point in this pipeline. [0] a businessconstraint to control sepecific operations by permissions could be solved by a shadowstructure like proposed by Bertrand. -- Dominik On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz <bdelacre...@apache.org>wrote: > On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß <dominik.su...@gmail.com> > wrote: > > Facing some questions about how to prevent the SlingPostServlet to be > able > > to perform a change I had a closer look at the current implementation and > > it looks like there is currently no "secure" way of doing that beside > > locking the target on persistancelevel (alias setting ACLs)... > > ...which looks to me like the right way of locking things. > > But maybe for the post servlet we need a parallel structure to define > who's allowed to do what. You could for example have > > /user-rights/sling/post-servlet/post/content/foo > > and whoever's allowed to read that is allowed to post to /content/foo, > barring other ACL limitations. > > Just thinking outloud mostly...my point is that any security-related > stuff should be driven by ACLs, and in some case "indirect" ACLs can > be useful. > > -Bertrand >
