Sorry, I should have attributed that code to Joel. -----Original Message----- From: Zappaterrini, Larry [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 10:56 AM To: users@wicket.apache.org Subject: RE: Double submit problem
I don't have a patch, at this point I was just testing the waters. I'm still new to Wicket and am learning about the goals of the community. If there is interest in this it is something I could pursue further. When I mentioned "not only does it prevent double submits" I was speaking to the concept of tokens. However Maurice's implementation looked correct to me short of actually testing it out. I formerly used Struts 1.2 and it has a similar feature that I've used successfully. Your last point is valid. Using the back button could get tricky with using a token. I'm not familiar with how Wicket handles back button support, but I imagine there would be a nice way to integrate token usage. Not all forms would require tokens. But for some critical forms you might desire the integrity that a token provides. For a back button click, you would have to interact with the user about their intentions. I'm thinking specifically of something like a bank account transfer. Using a token prevents CSRF and double submits. If the user clicks back and tries to submit again, you would probably want to get verification from them that they do in fact want to process the request again, or just force them to start over possibly. -----Original Message----- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 10:36 AM To: users@wicket.apache.org Subject: Re: Double submit problem do you have a good patch then? And are you saying that all double submits are then not possible anymore? Also when i submit then think hmm thats wrong back button change something and submit again? On Tue, Mar 25, 2008 at 3:25 PM, laz <[EMAIL PROTECTED]> wrote: > > Does anyone else feel that this would be generically useful to have as a > part > of Wicket? Not only does it prevent double submits, but it also is a > simple > safeguard against cross-site request forgery (see > http://en.wikipedia.org/wiki/Cross-site_request_forgery for a summary). > > The one missing piece from your solution is synchronization. There is the > slightest possibility that the second submit of a double submit could > enter > onSubmit before the token is reset. I am not yet sure what would be the > best > object to synchronize on, possibly the session id? > > > > hillj2 wrote: > > > > Here's a solution that SEEMS to be working. It incorporates our > solution > > to the double submit problem that we used on our JSP's. It didn't > appear > > to be working for me at first, but seems to be now. (It does use the > old > > servlet request/session objects, but this may change once all our old > code > > is upgraded to wicket.) > > > > ... > > > > Like I said, for now this appears to be working. I just extend all my > > forms from this class and implement onSubmitted() with the same code I > > previously put in onSubmit(). The key is putting matching unique > strings > > in session and in the page instance. On submit, those string should > > match, at which point, the string in session is cleared and the form is > > processed as normal. If another submit comes in, the string in session > > has been cleared so it doesn't match the string svaed in the page > > instance. In the case where setResponsePage is not called, > onBeforeRender > > resets the token string, so submitting from the refreshed page won't > > register as an error. > > > > Our JSP version of this involves putting the token string in session and > > also saving a copy to a hidden field on the JSP page. Which I think is > > similar (although maybe a bit more complex) to what Martijn was > > suggesting. > > > > Thanks for all you suggestions. > > > > Joel > > > > -- > View this message in context: > http://www.nabble.com/Double-submit-problem-tp15957979p16275106.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ______________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ______________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
