Rereading my post: you always trigger exactly one <add>:operation</add>, so this is not an aspect, this is wat actualy is done to perform the post.
On Wed, Jul 3, 2013 at 3:27 PM, Dominik Süß <dominik.su...@gmail.com> wrote: > 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 >> > >> >> > >> > >> > >
