cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: [lazy vote] cforms request processing
Date Tue, 02 Nov 2004 05:08:41 GMT
On Mon, Nov 01, 2004 at 06:13:21PM -0600, Antonio Gallardo wrote:
> Tim Larson dijo:
> > We have talked several times about changing the request
> > processing in cforms to not touch any widget whose
> > request parameter is missing (to prevent these widgets'
> > values from being reset to null,) the end result being
> > that it would be easier for the view to decide how to
> > split a form across multiple pages without breaking the
> > SoC between the form model and the view.
> Is not posible to do that before sending the page? IMO given blind truting
> to what the client is sending back is not good at all.

(Please see further down the page for a discussion on the
security aspects.)

An alternative that has been suggested in the past is to
collect a list of the widgets present in the view, and to
use this list to filter which widgets would get to process
their request parameters upon a POST.  The drawback to
this approach is that it would not work for stateless
forms, which is one of the use cases supported by cforms.

Since with stateless forms the form model gets recreated
on each POST, where would you store the view's widget
list?  And if the view is dynamic (uses union, choose,
if, etc.) then you would have to store the list per form
instance, clearly preventing stateless form semantics.

In contrast, the design presented in this lazy vote would
cause no problems for stateless form support because it
does not require storing the list of widgets currently
present in the view.

> This can open some posible security concerns at all?

The form model would still be in control of which request
parameters get processed.  The only change is that a missing
request parameter would cause no change to the corresponding
widget instead of causing it to be reset to null.  Can you
think of any way for this to be exploited?  A client could
change a value that was not made visible by the current page
view, but it would still be subject to the normal validation
rules.  And if this is an important issue for your use-case,
then your page-splitting is a data model (form model)
concern rather than a pure view concern and you should have
used a union/choose or other *model* means to control it.

In other words, excess request parameters would still be
ignored just like they are now, so this would _not_ open
a security hole like we had with xmlforms, so I do not
see a case of blind trust being given to the client.

> > As discussed before, this change would involve sending
> > a hidden field along with every checkbox to indicate
> > the presence of the checkbox, because an unchecked
> > checkbox does not generate a request parameter on POST.
> > This would allow to distinguish between a checkbox that
> > is unchecked versus a checkbox that is not on the page.
> What is the performance impact of that???

For each checkbox, we would send the client two widgets
instead of one, and on POST we would get two widgets back
instead of one.  This only affects checkboxes, not other
widgets such as fields, repeaters, etc.

> > What do we want to do?
> > [ ] leave as is
> > [ ] make the changes described above
> Hmm.. I am still not sure. Can you explain a little bit about the above
> first or just point to some links?

Please let me know whether the above explanation makes
sense or has holes in it, or if anybody has better ideas.

> Many thanks in advance. ;-)

No problem :)

--Tim Larson

View raw message