Ack on the overall goal. The way I see it, it boils down to having the sling post servlet (or more specifically that new POST-pipeline) not "just" one special servlet out of many, but an integral part of Sling.
Registering operations, post processors or whatever we need by resource type sounds good. By path not so much, don't know. IMHO, the rt would be taken from the addressed resource (what the URL addresses, to be 1:1 with how GET servlet resolution works; not any resources that additional request parameters might address) and if not present (creating a new resource) from the sling:resourceType param. It would actually be nice if those operations or postprocessor could become servlets or servlet filters again. They could get the necessary state passed via a request attribute for example + a utility to fetch them. And thinking about it, filters are actually the right thing, they are designed for pipelines. I am not sure if adding a :selector parameter as proposed by Justin (SLING-2936) is a good idea - maybe the integration with this new pipeline is the better long-term approach. You'd register by resource type + http method + :operation. Having both :operation and :selector (in the combined overall picture) seems like duplication. But it's difficult. It was mentioned that using selectors in the URL for POST requests, such as POST /content/page.createChild.html, is not RESTful. Is that really the case? As long as the server provides the URL instead of the client building it himself, such as <path> + ".createChild.html" as it happens way too much, and you use the right HTTP methods for changing/deleting content, nothing here would be unRESTful afaics. It would only look nicer if you put all the POST related information into the request parameters instead of into the URL. But then it's the old "action=create" topic again, which should be covered very well with the default features of the Sling post servlet already, which only requires you to add custom code (actions) for very specific things. This is even less once we have a validation framework in place (also resource type based), where Radu did a lot of work already! Cheers, Alex On 02.07.2013, at 15:26, Dominik Süß <dominik.su...@gmail.com> wrote: > 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 >>
