I'm wondering why the stripes form tag and stripes filter don't provide this automatically. It seems like everyone rolls their own version of this, and if they haven't yet they will eventually, since without such a check the application is easy to break.
I think this would be a good feature for stripes-stuff or stripes core even. I believe a lot of other web frameworks offer this right out of the box, and tout it as a useful and necessary feature, which it is. Am I wrong? I know the trend is to say "NO" to features and bloat, I agree with that generally, but this topic comes up a lot. It could be a big deal to force everyone to implement a new interface or something for handling the failure case, maybe a generic validation error could be used, idk. -----Original Message----- From: Oscar Westra van Holthe - Kind [mailto:os...@westravanholthe.nl] Sent: Tuesday, November 16, 2010 10:35 AM To: nikol...@brightminds.org; Stripes Users List Subject: Re: [Stripes-users] Preventing multiple form submission On 16-11-2010 at 10:17, Nikolaos Giannopoulos wrote: > Just wondering how others elegantly solve this situation: > > 1) User is editing a form and fills it out and clicks submit button > 2) Form gets successfully processed on the server however before a > response is returned the user hits the stop button, their internet > connection drops, etc... > 4) User clicks on submit again and tries to re-submit the same > information(*) > > Now, this would be trivial if there was a unique piece of information > in the content being posted however lets assume someone posting some > blog / news content wherein there is really no unique info (e.g. > although it may be rare there is nothing wrong with 2 people say > posting the same content with the same title). > > I was thinking to tag the users session with the last successfully > submitted Stripes "_sourcePage" field and direct the user to the "view" > handler if they are trying to do an "edit" and the "_sourcePage"matches. > > Thoughts??? It is always possible to render a hidden field "nonce" with a bit of opaque information (like a random long, hex-encoded), that is also stored in the session. Generally, you get a flow like this: - A form is prepared - Generate a few random bytes (e.g. a long, anf hex-encode it) - Store the value in the session - Display the form, including a hidden field "nonce" with the generated value ... - When receiving a request that's not intended for a default handler, check the field "nonce": - If it isn't present, give an error - If it is present but doesn't match the value in the session, present an error message "this form has already been submitted", and re-display the form or the detail page - Otherwise the nonce is present and matches the stored value: perfect - Unless there is an error (see above), proceed as usual As a variation you may generate a nonce per form or form/record combination to explicitly allow people to edit multiple things at once. Also, given that I match on "default handler or not", it is perfectly possible to handle this using an interceptor and custom form tag. The first check upon submit forced the use of the custom tag, so there will be no omissions there. Oscar -- ,-_ Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/ /() ) (__ ( Inequality is the inevitable consequence of liberty. =/ () -- Salvador De Madariaga - "Anarchy or Hierarchy" (1937) ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
