cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: [lazy vote] cforms request processing
Date Tue, 02 Nov 2004 21:26:32 GMT
Hi Tim:

As I told before I am not sure. I really want to see what the other people
will said here. I also already saw that Sylvain voted +1 for the changes.
But I am not sure if this is correct or not. That is all.

Tim Larson dijo:
> On Tue, Nov 02, 2004 at 02:38:24PM -0600, Antonio Gallardo wrote:
>> 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. ;-)
> If necessary, we could implement an in-form config that would
> choose between the two missing-request-parameter behaviors.

that will be better, I guess.

>> >> 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 ;-)
> Please see my other email for the @required answer.
> Summary: we still validate, the only change is we do not
> automatically reset to null, so @required widgets should
> still work as they do now.
>> > 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:
> I don't see how this change affects that scenario.
>> Under some condition this could allow to hack the form.
> Could you give such a sample condition?
>> 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.
> Please see the @require answer.
>> >> 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).
> If it is that bad, we could make a config for it, as mentioned above.
>> >> > 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. ;-)
> I do not mean to railroad this issue.  The lazy vote is just to
> get attention put on the issue so we can finally resolve it.
> I am not in a hurry, so let's make sure everybody is comfortable
> with whatever solution(s) we settle on :)

All in all, lets believe in our cforms-fw gurus: ;-)

[-0] make the changes described above

Best Regards,

Antonio Gallardo.

View raw message