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 > >> > >
