[Maypole] Patches to fix multiple form-submission issues
Perrin Harkins
perrin@elem.com
Fri, 14 May 2004 15:47:32 -0400
On Thu, 2004-05-13 at 15:50, Jesse Sheidlower wrote:
> The basic idea is that when a form is sent to the browser, it
> will include a random form_id variable, which should be placed
> in a hidden field; this variable is stored server-side in the
> session. When the form is submitted, the do_edit method will
> check to see if the form_id sent with the form matches the form_id
> held in the session; if it does, the session's copy is deleted
> (thus preventing a match if the form is resent) and life goes
> on. If it does not match, a message is generated, and the user
> is sent back to the "list" template. (Perhaps this isn't the
> best place to go.)
Interestingly, although that does appear to be what Randal was doing,
this is not how I would do it. I think that just goes to show that you
can only generalize the expected behavior of web apps so far.
What I would do is put the unique ID of a form into the session AFTER
processing it, and whenever a new update request comes in I would check
to see that it wasn't a form submission I already handled.
With the method you implemented, I would be concerned about multiple
windows being open. I don't want to stop users from opening multiple
windows with forms in them; I just want to only process each form
submission once. My approach (storing the already processed form ids)
doesn't have a problem with multiple windows.
- Perrin