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/07/02 14:38:30 UTC
Re: Sling Posthandling - thougts about the current behavior
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 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