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 20:55:51 GMT
On Tue, Nov 02, 2004 at 12:33:48PM -0700, Jason Johnston wrote:
> On Mon, 2004-11-01 at 22:08, Tim Larson wrote:
> > > 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.
> I'm concerned about a particular scenario; perhaps you can explain how
> this would work in the proposed behavior...
> It seems to me that implementing the proposal would make required="true"
> on widget definitions pretty much useless.  IIUC, such widgets would not
> be validated as required if their request parameters were not present. 
> So it would be possible to successfully submit (i.e. encounter no
> validation errors and pass successfully through the form.showForm()
> loop) a single-page form with a blank required field by simply removing
> that field's name from the request.
> This creates a problem where it's no longer guaranteed that the values
> in the form model post-validation are all valid; required widgets can
> have null values (assuming their initial values from form.load() were
> null).
> Is this actually the case in the proposal?  Thoughts on how this can be
> avoided?

We would still perform validation.  The only thing we would not do
is automatically reset a widget's value to null when its request
parameter is missing.  Because we would still validate the widget,
"required" widgets would still catch empty values like they do now.

--Tim Larson

View raw message