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)
Date: Tue, 2 Nov 2004 21:06:16 +0000
From: Tim Larson <tim@keow.org>
To: dev@cocoon.apache.org
Subject: Re: [lazy vote] cforms request processing
Message-ID: <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <33046.80.219.8.172.1099427904.squirrel@80.219.8.172>
User-Agent: Mutt/1.5.6i

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.

> >> 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 :)

--Tim Larson