cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <>
Subject Re: [lazy vote] cforms request processing
Date Tue, 02 Nov 2004 19:33:48 GMT
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

Is this actually the case in the proposal?  Thoughts on how this can be


View raw message