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). There is some hack to throw and exception from within the operationcode or a postprocessor which basically works as long as all operations and postprocessors respect this process as a transaction and do not commit via resourceresolver or JCR session.
When designing a refactoring I think it would be a good idea to enforce this transactional behavior. A transparent solution would be to wrap the resourceresolver to throw a corresponding exception when changes are commited during processing. When we have a Pipeline with multiple phases we should make sure that we have the first phases to have this hard contract not to be able to perform any change to the resourceresolver. I'm not so sure about how to handle actions on the JCR Session (or if there is a feasible way to suppress that at all) but at least for ResourceResolver that should be feasible. WDYT? Dominik On Fri, Jun 28, 2013 at 4:21 PM, Felix Meschberger <[email protected]>wrote: > Hi Radu > > That would be great ! Thanks. > > Regards > Felix > > Am 28.06.2013 um 12:49 schrieb Radu Cotescu: > > > Something might come up this afternoon for SLING-2803 [1]. :) > > > > [1] - https://issues.apache.org/jira/browse/SLING-2803 > > > > > >> As for validation: This is something we are sourely lacking in Sling > >> anyway. I think input validation is definitely something which should be > >> part of the default Sling POST Servlet processing. But it should also > be a > >> feature, which is available independently for those cases, where the > POST > >> request is fully handled outside of the POST servlet. > >> > >
