cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: [lazy vote] cforms request processing
Date Tue, 02 Nov 2004 20:38:24 GMT
Tim Larson dijo:
> 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.

I see the point.I am more convinced that we are pushing HTTP to the
maximum and we need more.... well, can we implement that only for
stateless forms? Why we need to cut all with the same scissors? This is
only a thought. ;-)

>> 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.

Somebody else on this thread mentioned about the @required. How we will
manage that, if we don't get back the required field? I answered below
this question ;-)

> 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.

Exploited? Not sure, but you can do pretty funny thing with the forms. For
example:

Given a form that first allow you to select a quantity discount: Said you
get 0% discount is you buy 1-10 items, 5% if you buy 11-20 items and 10%
if you buy 21 or more items.

Suppose the form first ask for the quantity to be buyed and then based on
this select a discount. Then you change the quantity to 1 and the discount
is already set. I know this is a very dumb sample, but the point I want to
show is:

Under some condition this could allow to hack the form.

Or what if I sent back an authentication form with empty fields? It hard
to think in a sample. And we know we never can trust on the client. This
is a basic web development rule. But in this caseI see we are trusting on
the client.....maybe we need to think a little bit more to see a sample.

We (programmers) are not perfect. I remember the infamous non-preemtive
windows 3.1 when you wrote a bad a application you could freeze all the
system.

> 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.

This is good.

>> > 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.

Remember on the repeaters we have the select boxes. If we are showing 20
rows on the repeater we are adding 20 new request params. I remember a
system that did that and then they fixed on the next release by allowing
users to define wich parameters need to return to the server to improve
the performance.... I just expect this could not be our bottleneck later.
More hidden parameters also mean bigger responses (pages).

>> > What do we want to do?
>> > [ ] leave as is
>> > [ ] make the changes described above

Please think about that. I am sure you have the best intentions to improve
the cforms-fw. To be honest I am not sure how to vote in this case, so is
this is a big problem. I can put a -0 (this is not a VETO) for that. Let's
see what the other people has to said about that. ;-)
>>
>> 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 :)

:-D

Best Regards,

Antonio Gallardo

Mime
View raw message