If I got the implementation right you always trigger exactly one, so this is not an aspect, this is wat actualy is done to perform the post. Aspects are handled via PostProcessors.
On Wed, Jul 3, 2013 at 2:58 PM, Justin Edelson <jus...@justinedelson.com>wrote: > Hi, > > > On Tue, Jul 2, 2013 at 2:38 PM, Alexander Klimetschek <aklim...@adobe.com > >wrote: > > > 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. > > > > Why wouldn't you register by resource type + method + selector? After all, > that's what you do now. For pipeline components, we could add a "phase" > registration property (or maybe ranking is enough). > > IMHO :operation is an aspect of the current default POST servlet. If we are > going to move more POST-specific handling into the engine, then we should > be using selectors. > > Justin > > > > 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 > > >> > > > > >
