cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nuno Santos <>
Subject Re: [lazy vote] cforms request processing
Date Tue, 02 Nov 2004 18:49:01 GMT
The Request interface has a method to get an enumeration of parameter
names( getParameterNames), so just check the existence of the widget
Request parameter name and process only if exist!

On Tue, 2004-11-02 at 05:08, Tim Larson wrote:
> 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
Nuno Santos <>
Electroplus, lda

View raw message