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.
