You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Dominik Süß <do...@gmail.com> on 2013/06/26 12:35:44 UTC
Sling Posthandling - thougts about the current behavior
Hi everyone,
within the last weeks I spent some time on a project that is heavily
relying on data being submitted by users of the system and setting up
complex structures, users, groups and ACLs based on the operations
performed by a user. I reallized that a lot of those things could be done
by utilizing the SlingPostServlet and extending it by custom Postprocessors
and custom operations. This worked out well but I realized some things that
I'm not so happy with and would like to start off a discussion how the
handling of Posts, and therefore the interactive part of Sling could be
improved.
Here the points that I think are "discussabble":
a) (non-Brainer) Postoperations and Postprocessors are rarely covered by
documentation (Postprocessors are marked as TBD) this gives the impression
of not being ready for productive usage so the gap should be closed
b) Postoperations and Postprocessors are always defined and called global
so it is up to the developer to check and skip processing (Blacklisting
approach) which is errorprone if this manual check is not restrictive
enough (can lead to subtle regressions in completely different areas of the
app) - I'd propose to have a declarative approach that is a
whitelistapproach based on path and propably even by resourceType (here
comes the clash between posted resourceType and potentially already
existing resourceType
c) Sometimes data submitted should just be used as parameters for
postprocessors or operations and not persisted. Using the dot-slash
prefixing does give such options, but since the "./" notation acts as kind
of a magic trigger of behaviour I'd prefer to have a way to annotate such
fields (like name@ignore or @noPersistance)
All in all the web is moving in a direction where almost no page is
delivered with options to interact with the the webpage - so Sling should
try to give developers the tools to do this wireing without having the dev
to write boilerplatecode for those checks over and over again and enabling
them to implement complete interactive userstories up to a certain point of
complexity in a standardized way.
WDYT?
Best regards
Dominik
Re: Sling Posthandling - thougts about the current behavior
Posted by Dominik Süß <do...@gmail.com>.
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üß <do...@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 <ju...@justinedelson.com>wrote:
>
>> Hi,
>>
>>
>> On Tue, Jul 2, 2013 at 2:38 PM, Alexander Klimetschek <aklimets@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üß <do...@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
>> > > <bd...@apache.org>wrote:
>> > >
>> > >> On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß <dominik.suess@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
>> > >>
>> >
>> >
>>
>
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Dominik Süß <do...@gmail.com>.
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 <ju...@justinedelson.com>wrote:
> Hi,
>
>
> On Tue, Jul 2, 2013 at 2:38 PM, Alexander Klimetschek <aklimets@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üß <do...@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
> > > <bd...@apache.org>wrote:
> > >
> > >> On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß <do...@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
> > >>
> >
> >
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 03.07.2013, at 14:58, Justin Edelson <ju...@justinedelson.com> wrote:
> 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.
Yes, my main point was to have only one. You are right, selector is the broader concept, so we could drop operation here.
Looking at the existing operations [0], IMO all of them could/should be replaced by a param@Something style notation. We do this with @CopyFrom already, same could be done with @Checkin etc. Even "import" can be done this way.
This moves it down from some request-global operation to a parameter specific option, with the benefit of allowing multiple ones in a single request. Then the POST is always the default create-or-modify operation.
With the new pipeline, things can hook in and either overlay the default behaviour for certain parameters or handle custom ones (as PostProcessors typically do). We should make it simpler to read and modify the special RequestParameter map that is passed through, it is currently quite some work to read a custom @Something and get the right path for it etc.
[0] http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html#ManipulatingContent-TheSlingPostServlet%2528servlets.post%2529-SlingPostServletOperations
Cheers,
Alex
Re: Sling Posthandling - thougts about the current behavior
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jul 3, 2013 at 2:53 PM, Dominik Süß <do...@gmail.com> wrote:
> ...I bet a bunch of
> scripts/servlet currently check the contentpath first and react on this...
Those servlets should die ;-)
-Bertrand
Re: Sling Posthandling - thougts about the current behavior
Posted by Dominik Süß <do...@gmail.com>.
As said before - I would never register a Servlet by path, but a Servlet
serving a specific ResourceType might just be valid for a specific path.
(like extension or selector can filter the selection of the matching
Servlet/Script). I agree that in contrast to Servlets and Extensions it's
not feasible to encode this in the script, but I bet a bunch of
scripts/servlet currently check the contentpath first and react on this
Dominik
On Wed, Jul 3, 2013 at 2:38 PM, Justin Edelson <ju...@justinedelson.com>wrote:
> Hi Dominik,
> Wouldn't a ResourceDecorator be a better solution in those case? I.e. if a
> resource is of type app/foo and is under /content/bar, decorate the
> resource to app/bar ?
>
> The fact that you can register servlets by path should *not* in my opinion
> be a reason to extend behavior-by-path to other parts of Sling.
>
> Regards,
> Justin
>
>
> On Wed, Jul 3, 2013 at 8:22 AM, Dominik Süß <do...@gmail.com>
> wrote:
>
> > Hi Bertrand,
> >
> > while I agree that paths should not drive the app they might build a
> scope
> > for the logic, since the content is organized in a tree structure and not
> > in by it's resourceType hierarchy, Therefore you often do have
> pathspecific
> > operations (just think of workflows and workflowlaunchers in CQ). Or to
> > come up with another scenario.
> > Changing resourceTypes depending on the location of the same data on the
> > other hand would be redundant information.
> >
> > So - the main Driver should be the resourceType is what is defining the
> > behavior of a component while the contentpath in my eyes could act as
> > restricting criteria.
> >
> > WDYT?
> >
> >
> > On Wed, Jul 3, 2013 at 1:22 PM, Bertrand Delacretaz
> > <bd...@apache.org>wrote:
> >
> > > Hi,
> > >
> > > On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß <do...@gmail.com>
> > > wrote:
> > > > ...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....
> > >
> > > In general we want people to get away from the notion that paths drive
> > > your app, it should be resource types that do.
> > >
> > > Also, the problem with paths is that they are usually hidden in code,
> > > whereas resource types are transparently exposed in the content.
> > >
> > > For the POST handling, we could very well take the resource type of
> > > the parent/ancestors into account, instead of relying on paths.
> > >
> > > -Bertrand
> > >
> >
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jul 3, 2013 at 2:38 PM, Justin Edelson <ju...@justinedelson.com> wrote:
>... Wouldn't a ResourceDecorator be a better solution in those case? I.e. if a
> resource is of type app/foo and is under /content/bar, decorate the
> resource to app/bar ?...
Note that we already have something like that in
http://svn.apache.org/repos/asf/sling/trunk/samples/path-based-rtp/
-Bertrand
Re: Sling Posthandling - thougts about the current behavior
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi Dominik,
Wouldn't a ResourceDecorator be a better solution in those case? I.e. if a
resource is of type app/foo and is under /content/bar, decorate the
resource to app/bar ?
The fact that you can register servlets by path should *not* in my opinion
be a reason to extend behavior-by-path to other parts of Sling.
Regards,
Justin
On Wed, Jul 3, 2013 at 8:22 AM, Dominik Süß <do...@gmail.com> wrote:
> Hi Bertrand,
>
> while I agree that paths should not drive the app they might build a scope
> for the logic, since the content is organized in a tree structure and not
> in by it's resourceType hierarchy, Therefore you often do have pathspecific
> operations (just think of workflows and workflowlaunchers in CQ). Or to
> come up with another scenario.
> Changing resourceTypes depending on the location of the same data on the
> other hand would be redundant information.
>
> So - the main Driver should be the resourceType is what is defining the
> behavior of a component while the contentpath in my eyes could act as
> restricting criteria.
>
> WDYT?
>
>
> On Wed, Jul 3, 2013 at 1:22 PM, Bertrand Delacretaz
> <bd...@apache.org>wrote:
>
> > Hi,
> >
> > On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß <do...@gmail.com>
> > wrote:
> > > ...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....
> >
> > In general we want people to get away from the notion that paths drive
> > your app, it should be resource types that do.
> >
> > Also, the problem with paths is that they are usually hidden in code,
> > whereas resource types are transparently exposed in the content.
> >
> > For the POST handling, we could very well take the resource type of
> > the parent/ancestors into account, instead of relying on paths.
> >
> > -Bertrand
> >
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Dominik Süß <do...@gmail.com>.
Hi Bertrand,
while I agree that paths should not drive the app they might build a scope
for the logic, since the content is organized in a tree structure and not
in by it's resourceType hierarchy, Therefore you often do have pathspecific
operations (just think of workflows and workflowlaunchers in CQ). Or to
come up with another scenario.
Changing resourceTypes depending on the location of the same data on the
other hand would be redundant information.
So - the main Driver should be the resourceType is what is defining the
behavior of a component while the contentpath in my eyes could act as
restricting criteria.
WDYT?
On Wed, Jul 3, 2013 at 1:22 PM, Bertrand Delacretaz
<bd...@apache.org>wrote:
> Hi,
>
> On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß <do...@gmail.com>
> wrote:
> > ...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....
>
> In general we want people to get away from the notion that paths drive
> your app, it should be resource types that do.
>
> Also, the problem with paths is that they are usually hidden in code,
> whereas resource types are transparently exposed in the content.
>
> For the POST handling, we could very well take the resource type of
> the parent/ancestors into account, instead of relying on paths.
>
> -Bertrand
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß <do...@gmail.com> wrote:
> ...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....
In general we want people to get away from the notion that paths drive
your app, it should be resource types that do.
Also, the problem with paths is that they are usually hidden in code,
whereas resource types are transparently exposed in the content.
For the POST handling, we could very well take the resource type of
the parent/ancestors into account, instead of relying on paths.
-Bertrand
Re: Sling Posthandling - thougts about the current behavior
Posted by Dominik Süß <do...@gmail.com>.
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 <ak...@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üß <do...@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
> > <bd...@apache.org>wrote:
> >
> >> On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß <do...@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
> >>
>
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jul 3, 2013 at 2:58 PM, Justin Edelson <ju...@justinedelson.com> wrote:
> ...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)....
And phase could be just a fake selector, PPP_foo or something where
PP_ means "POST Pipeline Phase".
-Bertrand
Re: Sling Posthandling - thougts about the current behavior
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi,
On Tue, Jul 2, 2013 at 2:38 PM, Alexander Klimetschek <ak...@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üß <do...@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
> > <bd...@apache.org>wrote:
> >
> >> On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß <do...@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
> >>
>
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Alexander Klimetschek <ak...@adobe.com>.
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üß <do...@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
> <bd...@apache.org>wrote:
>
>> On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß <do...@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
>>
Re: Sling Posthandling - thougts about the current behavior
Posted by Dominik Süß <do...@gmail.com>.
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
<bd...@apache.org>wrote:
> On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß <do...@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
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß <do...@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
Re: Sling Posthandling - thougts about the current behavior
Posted by Dominik Süß <do...@gmail.com>.
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). There is some
hack to throw and exception from within the operationcode or a
postprocessor which basically works as long as all operations and
postprocessors respect this process as a transaction and do not commit via
resourceresolver or JCR session.
When designing a refactoring I think it would be a good idea to enforce
this transactional behavior. A transparent solution would be to wrap the
resourceresolver to throw a corresponding exception when changes are
commited during processing. When we have a Pipeline with multiple phases
we should make sure that we have the first phases to have this hard
contract not to be able to perform any change to the resourceresolver. I'm
not so sure about how to handle actions on the JCR Session (or if there is
a feasible way to suppress that at all) but at least for ResourceResolver
that should be feasible.
WDYT?
Dominik
On Fri, Jun 28, 2013 at 4:21 PM, Felix Meschberger <fm...@adobe.com>wrote:
> Hi Radu
>
> That would be great ! Thanks.
>
> Regards
> Felix
>
> Am 28.06.2013 um 12:49 schrieb Radu Cotescu:
>
> > Something might come up this afternoon for SLING-2803 [1]. :)
> >
> > [1] - https://issues.apache.org/jira/browse/SLING-2803
> >
> >
> >> As for validation: This is something we are sourely lacking in Sling
> >> anyway. I think input validation is definitely something which should be
> >> part of the default Sling POST Servlet processing. But it should also
> be a
> >> feature, which is available independently for those cases, where the
> POST
> >> request is fully handled outside of the POST servlet.
> >>
>
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Radu
That would be great ! Thanks.
Regards
Felix
Am 28.06.2013 um 12:49 schrieb Radu Cotescu:
> Something might come up this afternoon for SLING-2803 [1]. :)
>
> [1] - https://issues.apache.org/jira/browse/SLING-2803
>
>
>> As for validation: This is something we are sourely lacking in Sling
>> anyway. I think input validation is definitely something which should be
>> part of the default Sling POST Servlet processing. But it should also be a
>> feature, which is available independently for those cases, where the POST
>> request is fully handled outside of the POST servlet.
>>
Re: Sling Posthandling - thougts about the current behavior
Posted by Radu Cotescu <ra...@cotescu.com>.
Something might come up this afternoon for SLING-2803 [1]. :)
[1] - https://issues.apache.org/jira/browse/SLING-2803
> As for validation: This is something we are sourely lacking in Sling
> anyway. I think input validation is definitely something which should be
> part of the default Sling POST Servlet processing. But it should also be a
> feature, which is available independently for those cases, where the POST
> request is fully handled outside of the POST servlet.
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Thanks Dominik for bringing this up. I really like the direction this discussion is taking.
We really learned a lot about the Sling POST Servlet since we first created it and it is probably time for a complete rearchitecture.
> If we can also consider the post servlet as a pipeline of operations
> (validate, pre-process, store etc.) we'd have a flexible mechanism
> where you can avoid registering too many global things.
A Pipeline sounds great.
As for validation: This is something we are sourely lacking in Sling anyway. I think input validation is definitely something which should be part of the default Sling POST Servlet processing. But it should also be a feature, which is available independently for those cases, where the POST request is fully handled outside of the POST servlet.
> I have long thought SlingPostOperations should be registered against the
> resource type in the same way SlingServlets are registered against a
> resource type.
+1 I think all extension points for the POST servlet (as well as the future input validation framework) should be configurable with a resource type.
> I also +1 the idea of having a pipeline with different stages of
> processing where a dev can hook in based on some criteria (like
> resourcetype, path, extension and so on) to be able to break down the
> processing in the various aspects and therefore be able to implement
> reusable parts.
But I think neither the request selectors nor the request extension should be taken into account. The request URL should solely be addressing the resource and -- as a compromise to not being able to fully influence the Accept request header -- the resource representation. It should never contain request methods.
Taking the resource path into consideration is interesting, though: For now we completely ignore the resource path in any resolution of scripts, filters and servlets. I fully agree, it may make sense for POST processing and for filters. But, would it maybe also make sense for general script and servlet resolution ? And if so, how ? (please spawn a new thread if you want to discuss this, thanks)
Regards
Felix
Am 28.06.2013 um 11:15 schrieb Dominik Süß:
> As far as I got it right most agree that it would be great to have an
> optimized way to utilize the SlingPostServlet.
> I also +1 the idea of having a pipeline with different stages of
> processing where a dev can hook in based on some criteria (like
> resourcetype, path, extension and so on) to be able to break down the
> processing in the various aspects and therefore be able to implement
> reusable parts.
>
> There also where some concerns about having this as the only way of
> posting. And I also +1 that the support of custom Servlets should be
> optimized anyway and not be dropped. If a developer decides to get rid of
> this pipeline and taking care of all the aspects on his own he should be
> free to do that. In this case he would (intentionally) lose all the
> implicit logic provided by the SlingPostServlet and is completely on his
> own just having the SlingHttpServletResquest & Response like for the GET
> Servlets.
>
> I think the next step would be to define the pipeline, the serverside logic
> that is applied on each step and the criteteria that shall be available to
> register the extensions. An interesting aspect of that is transactional
> behavior (like preventing session.save() up to a certain point in the
> pipeline to have a contract how long the data in any case is just in a
> transient state).
>
> Another idea that came into my mind on validation is the possiblity to have
> the post params returned in an annotated response that allows the client to
> resolve the problems and resubmit this (like Oak will be able to return
> such Conflictannotations on Concurrent Changes on a node). And this could
> also be used to implement multistepforms that need to be verified on the
> intermediate steps without actually persisting something (creating a
> restfull multistep form that way).
>
> WDYT?
> Dominik
>
>
>
>
> On Fri, Jun 28, 2013 at 8:51 AM, Daniel Platon <dp...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> I stand corrected, such a feature would not remove the SlingServlets
>> entirely from the picture, since they are still needed for GET requests.
>>
>> +1 for the "pipeline of operations" concept.
>>
>> __
>> Dan
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-sling.73963.n3.nabble.com/Sling-Posthandling-thougts-about-the-current-behavior-tp4024713p4024751.html
>> Sent from the Sling - Dev mailing list archive at Nabble.com.
>>
Re: Sling Posthandling - thougts about the current behavior
Posted by Dominik Süß <do...@gmail.com>.
As far as I got it right most agree that it would be great to have an
optimized way to utilize the SlingPostServlet.
I also +1 the idea of having a pipeline with different stages of
processing where a dev can hook in based on some criteria (like
resourcetype, path, extension and so on) to be able to break down the
processing in the various aspects and therefore be able to implement
reusable parts.
There also where some concerns about having this as the only way of
posting. And I also +1 that the support of custom Servlets should be
optimized anyway and not be dropped. If a developer decides to get rid of
this pipeline and taking care of all the aspects on his own he should be
free to do that. In this case he would (intentionally) lose all the
implicit logic provided by the SlingPostServlet and is completely on his
own just having the SlingHttpServletResquest & Response like for the GET
Servlets.
I think the next step would be to define the pipeline, the serverside logic
that is applied on each step and the criteteria that shall be available to
register the extensions. An interesting aspect of that is transactional
behavior (like preventing session.save() up to a certain point in the
pipeline to have a contract how long the data in any case is just in a
transient state).
Another idea that came into my mind on validation is the possiblity to have
the post params returned in an annotated response that allows the client to
resolve the problems and resubmit this (like Oak will be able to return
such Conflictannotations on Concurrent Changes on a node). And this could
also be used to implement multistepforms that need to be verified on the
intermediate steps without actually persisting something (creating a
restfull multistep form that way).
WDYT?
Dominik
On Fri, Jun 28, 2013 at 8:51 AM, Daniel Platon <dp...@gmail.com> wrote:
> Hi everyone,
>
> I stand corrected, such a feature would not remove the SlingServlets
> entirely from the picture, since they are still needed for GET requests.
>
> +1 for the "pipeline of operations" concept.
>
> __
> Dan
>
>
>
>
> --
> View this message in context:
> http://apache-sling.73963.n3.nabble.com/Sling-Posthandling-thougts-about-the-current-behavior-tp4024713p4024751.html
> Sent from the Sling - Dev mailing list archive at Nabble.com.
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Daniel Platon <dp...@gmail.com>.
Hi everyone,
I stand corrected, such a feature would not remove the SlingServlets
entirely from the picture, since they are still needed for GET requests.
+1 for the "pipeline of operations" concept.
__
Dan
--
View this message in context: http://apache-sling.73963.n3.nabble.com/Sling-Posthandling-thougts-about-the-current-behavior-tp4024713p4024751.html
Sent from the Sling - Dev mailing list archive at Nabble.com.
Re: Sling Posthandling - thougts about the current behavior
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jun 27, 2013 at 2:03 PM, Daniel Platon <dp...@gmail.com> wrote:
> ...I think such a feature would make binding the SlingServlets to
> resource type obsolete...
Now you got my attention...but you'll need to clarify your use case
and ideas I guess ;-)
-Bertrand
Re: Sling Posthandling - thougts about the current behavior
Posted by Daniel Platon <dp...@gmail.com>.
Hi everyone,
Although I don't have that much experience with Sling, I'd +1 any feature
that allows the developer to attach behaviour to content (at least this is
what a PostProcessor sounds to me). I made extensive use of such a feature
when I use to developer content management application on Documentum.
Also, I think such a feature would make binding the SlingServlets to
resource type obsolete...
_
Dan
--
View this message in context: http://apache-sling.73963.n3.nabble.com/Sling-Posthandling-thougts-about-the-current-behavior-tp4024713p4024725.html
Sent from the Sling - Dev mailing list archive at Nabble.com.
RE: Sling Posthandling - thougts about the current behavior
Posted by Jeff Young <je...@adobe.com>.
+1
That would be very nice.
Jeff.
> -----Original Message-----
> From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
> Sent: 27 June 2013 08:26
> To: dev@sling.apache.org
> Subject: Re: Sling Posthandling - thougts about the current behavior
>
> On Thu, Jun 27, 2013 at 12:52 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> > ...I have long thought SlingPostOperations should be registered against the
> > resource type in the same way SlingServlets are registered against a
> > resource type....
>
> Absolutely - there are other things (validation etc.) where we would
> benefit from using a similar same resource -> X resolution that we
> have for resource -> servlet, so we should generalize the mechanism.
>
> If we can also consider the post servlet as a pipeline of operations
> (validate, pre-process, store etc.) we'd have a flexible mechanism
> where you can avoid registering too many global things.
>
> -Bertrand
Re: Sling Posthandling - thougts about the current behavior
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jun 27, 2013 at 12:52 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...I have long thought SlingPostOperations should be registered against the
> resource type in the same way SlingServlets are registered against a
> resource type....
Absolutely - there are other things (validation etc.) where we would
benefit from using a similar same resource -> X resolution that we
have for resource -> servlet, so we should generalize the mechanism.
If we can also consider the post servlet as a pipeline of operations
(validate, pre-process, store etc.) we'd have a flexible mechanism
where you can avoid registering too many global things.
-Bertrand
Re: Sling Posthandling - thougts about the current behavior
Posted by Ian Boston <ie...@tfd.co.uk>.
Hi,
I have long thought SlingPostOperations should be registered against the
resource type in the same way SlingServlets are registered against a
resource type.
If the operation requested is not found against the resource type then the
parent resource types are tried until the global scope. That will give
operations like move becoming meaningless in anything other than the global
context. I dont think it would that hard to do, Sling already has a
resource type hierarchy and extension mechanism.
Best Regards
Ian
On 26 June 2013 20:35, Dominik Süß <do...@gmail.com> wrote:
> Hi everyone,
>
> within the last weeks I spent some time on a project that is heavily
> relying on data being submitted by users of the system and setting up
> complex structures, users, groups and ACLs based on the operations
> performed by a user. I reallized that a lot of those things could be done
> by utilizing the SlingPostServlet and extending it by custom Postprocessors
> and custom operations. This worked out well but I realized some things that
> I'm not so happy with and would like to start off a discussion how the
> handling of Posts, and therefore the interactive part of Sling could be
> improved.
>
> Here the points that I think are "discussabble":
> a) (non-Brainer) Postoperations and Postprocessors are rarely covered by
> documentation (Postprocessors are marked as TBD) this gives the impression
> of not being ready for productive usage so the gap should be closed
> b) Postoperations and Postprocessors are always defined and called global
> so it is up to the developer to check and skip processing (Blacklisting
> approach) which is errorprone if this manual check is not restrictive
> enough (can lead to subtle regressions in completely different areas of the
> app) - I'd propose to have a declarative approach that is a
> whitelistapproach based on path and propably even by resourceType (here
> comes the clash between posted resourceType and potentially already
> existing resourceType
> c) Sometimes data submitted should just be used as parameters for
> postprocessors or operations and not persisted. Using the dot-slash
> prefixing does give such options, but since the "./" notation acts as kind
> of a magic trigger of behaviour I'd prefer to have a way to annotate such
> fields (like name@ignore or @noPersistance)
>
> All in all the web is moving in a direction where almost no page is
> delivered with options to interact with the the webpage - so Sling should
> try to give developers the tools to do this wireing without having the dev
> to write boilerplatecode for those checks over and over again and enabling
> them to implement complete interactive userstories up to a certain point of
> complexity in a standardized way.
>
> WDYT?
>
> Best regards
> Dominik
>
Re: Sling Posthandling - thougts about the current behavior
Posted by Ondrej Florian <of...@adobe.com>.
...what about using POST.jsp for validations, implementing custom behavior etc.
in POST.jsp
* add / remove / modify / handle post parameters
* call the default POST servlet to do the actually persistence
* handle any errors
---
The reason why it doesn't work at the moment is that:
- post parameters are not mutable
- it is hard to call the default implementation (perhaps I just don't know how)
- exceptions coming from the POST servlet may not be detailed enough in order to provide error handling on granularity needed
I think approach could be very useful for intercepting other requests as well,without need to write custom filters.
Ondrej
On 26 Jun 2013, at 12:35, Dominik Süß <do...@gmail.com> wrote:
> Hi everyone,
>
> within the last weeks I spent some time on a project that is heavily
> relying on data being submitted by users of the system and setting up
> complex structures, users, groups and ACLs based on the operations
> performed by a user. I reallized that a lot of those things could be done
> by utilizing the SlingPostServlet and extending it by custom Postprocessors
> and custom operations. This worked out well but I realized some things that
> I'm not so happy with and would like to start off a discussion how the
> handling of Posts, and therefore the interactive part of Sling could be
> improved.
>
> Here the points that I think are "discussabble":
> a) (non-Brainer) Postoperations and Postprocessors are rarely covered by
> documentation (Postprocessors are marked as TBD) this gives the impression
> of not being ready for productive usage so the gap should be closed
> b) Postoperations and Postprocessors are always defined and called global
> so it is up to the developer to check and skip processing (Blacklisting
> approach) which is errorprone if this manual check is not restrictive
> enough (can lead to subtle regressions in completely different areas of the
> app) - I'd propose to have a declarative approach that is a
> whitelistapproach based on path and propably even by resourceType (here
> comes the clash between posted resourceType and potentially already
> existing resourceType
> c) Sometimes data submitted should just be used as parameters for
> postprocessors or operations and not persisted. Using the dot-slash
> prefixing does give such options, but since the "./" notation acts as kind
> of a magic trigger of behaviour I'd prefer to have a way to annotate such
> fields (like name@ignore or @noPersistance)
>
> All in all the web is moving in a direction where almost no page is
> delivered with options to interact with the the webpage - so Sling should
> try to give developers the tools to do this wireing without having the dev
> to write boilerplatecode for those checks over and over again and enabling
> them to implement complete interactive userstories up to a certain point of
> complexity in a standardized way.
>
> WDYT?
>
> Best regards
> Dominik