Hi Alex, why do you think registering logic by path is bad. Especially if I look at potential for multitenantsupport it would be great to be able to register postbehavior that is tenantspecific. And the tenantsupport of Sling is completely based on paths.
Regarding usage of Servlet Filters as pipelline I personally think this could probably get a bit intransparent for develpers. As previously mentioned the various phases should/would give the option to have a contract about what can be done during that phase. A filterbased handling just would give the option to control order of execution, but any filter could break this "transactional" contract. The injection of such a pipeline without the need to touch the existing servlet could be done via a filter, but I think it would make sense to optimize the current implementation when introducing such a mechanism. Just my 2 cents Dominik On Tue, Jul 2, 2013 at 8: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. > > 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 > >> > >
