On Mon, 2004-11-01 at 22:08, Tim Larson wrote: > > 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. 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. 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.
I'm concerned about a particular scenario; perhaps you can explain how this would work in the proposed behavior... It seems to me that implementing the proposal would make required="true" on widget definitions pretty much useless. IIUC, such widgets would not be validated as required if their request parameters were not present. So it would be possible to successfully submit (i.e. encounter no validation errors and pass successfully through the form.showForm() loop) a single-page form with a blank required field by simply removing that field's name from the request. This creates a problem where it's no longer guaranteed that the values in the form model post-validation are all valid; required widgets can have null values (assuming their initial values from form.load() were null). Is this actually the case in the proposal? Thoughts on how this can be avoided? --Jason
