Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <33152.80.219.8.172.1099430792.squirrel@80.219.8.172>
In-Reply-To: <20041102210616.GF21226@localhost>
References: <20041101144706.GM26283@localhost>
    <32899.80.219.8.172.1099354401.squirrel@80.219.8.172>
    <20041102050841.GD21226@localhost>
    <33046.80.219.8.172.1099427904.squirrel@80.219.8.172>
    <20041102210616.GF21226@localhost>
Date: Tue, 2 Nov 2004 15:26:32 -0600 (CST)
Subject: Re: [lazy vote] cforms request processing
From: "Antonio Gallardo" <agallardo@agssa.net>
To: dev@cocoon.apache.org
User-Agent: SquirrelMail/1.4.3a-1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

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.