Hi, No one else answered your email and I guess they have the same problem as me - I don't really understand the problem you describe.
You submit some form. Then you _intercept_ the request somehow and you append some extra data. And finally your concern is that there is extra data. What I don't understand is: are you describing a security issue ? If YES then use CRSF protection and/or CryptoMapper and/or custom token. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, May 16, 2016 at 1:02 PM, Samu Viitanen <zampp...@hotmail.com> wrote: > Hello Wicket Users, > > I am a relatively new developer working with wicket. I have come across a > strange feature that could cause problems in my project. When I submit a > form that has validation errors and intercept the resulting POST request, I > can insert query parameters in the URL. These query parameter values will > then be appended after the original POST parameter. > > Example: > > > /foo/fooAdmin?7-1.IBehaviorListener.0-admintabs-panel-wrapperform-tabbedpanel-panel-infoform-infosubmit&wicket-ajax=true&wicket-ajax-baseurl=fooAdmin%3F > > Will result in validation error. The request has POST parameters: > tabbedpanel:panel:infoform:foo=This is not empty > tabbedpanel:panel:infoform:bar= <- this field is required > but empty in request > tabbedpanel:panel:infoform:zoo= <- this field is not > required but empty in request > > I intercept the request with BurpSuite and modify the request: > > > /foo/fooAdmin?7-1.IBehaviorListener.0-admintabs-panel-wrapperform-tabbedpanel-panel-infoform-infosubmit&wicket-ajax=true&wicket-ajax-baseurl=fooAdmin%3F&tabbedpanel:panel:infoform:zoo=Haxor > > Results in error with TextField values: > foo=This is not empty > bar= <- Error > zoo=;Haxor > > This behaviour obviously does not directly save anything, but if the user > does not notice that a Text Field value has changed, he might save > something that he did not intend to. NOTE: The inserted value does not > replace the original value of the field, it just appends the new value to > the original value in the POSTDATA. (zoo=Value -> zoo=Value;Haxor after > attack) > > So I guess my question is: Is this intended? If so, is there a way around > this or do I have to live with it? > > Thank you for your replies > > Samu Viitanen >
