The Request interface has a method to get an enumeration of parameter names( getParameterNames), so just check the existence of the widget Request parameter name and process only if exist!
On Tue, 2004-11-02 at 05:08, Tim Larson wrote: > On Mon, Nov 01, 2004 at 06:13:21PM -0600, Antonio Gallardo wrote: > > Tim Larson dijo: > > > We have talked several times about changing the request > > > processing in cforms to not touch any widget whose > > > request parameter is missing (to prevent these widgets' > > > values from being reset to null,) the end result being > > > that it would be easier for the view to decide how to > > > split a form across multiple pages without breaking the > > > SoC between the form model and the view. > > > > Is not posible to do that before sending the page? IMO given blind truting > > to what the client is sending back is not good at all. > > (Please see further down the page for a discussion on the > security aspects.) > > An alternative that has been suggested in the past is to > collect a list of the widgets present in the view, and to > use this list to filter which widgets would get to process > their request parameters upon a POST. The drawback to > this approach is that it would not work for stateless > forms, which is one of the use cases supported by cforms. > > Since with stateless forms the form model gets recreated > on each POST, where would you store the view's widget > list? And if the view is dynamic (uses union, choose, > if, etc.) then you would have to store the list per form > instance, clearly preventing stateless form semantics. > > In contrast, the design presented in this lazy vote would > cause no problems for stateless form support because it > does not require storing the list of widgets currently > present in the view. > > > 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. > > In other words, excess request parameters would still be > ignored just like they are now, so this would _not_ open > a security hole like we had with xmlforms, so I do not > see a case of blind trust being given to the client. > > > > As discussed before, this change would involve sending > > > a hidden field along with every checkbox to indicate > > > the presence of the checkbox, because an unchecked > > > checkbox does not generate a request parameter on POST. > > > This would allow to distinguish between a checkbox that > > > is unchecked versus a checkbox that is not on the page. > > > > 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. > > > > What do we want to do? > > > [ ] leave as is > > > [ ] make the changes described above > > > > Hmm.. I am still not sure. Can you explain a little bit about the above > > first or just point to some links? > > Please let me know whether the above explanation makes > sense or has holes in it, or if anybody has better ideas. > > > Many thanks in advance. ;-) > > No problem :) > > --Tim Larson -- Nuno Santos <[EMAIL PROTECTED]> Electroplus, lda
