RE: Question on Double Submit and rendering strategy

[Bernard Bernard <bh...@gmail.com>]

Hi Mark,

I read your post on the Wicket users list.

Prevention of double submits can safely be achieved with an old J2EE design
pattern, a server token.

So the server generates a token for the form and expects it on submission.
After the first submission it is invalidated and subsequent submissions
will get a different response.

In Wicket, this is very easy to solve 1) if one includes the server token
in a form field (interestingly, the page already has a token to prevent
CSRF attacks), and 2) if one ensures that there is only a single instance
of the page for an existing session.

This is a stateful solution obviously but here, server state really pays
dividends.

There might be issues with forcing a single page instance per session, but
it is possible that any other mechanism implementing the server side token
pattern suffer from similar issues.

Please see https://issues.apache.org/jira/browse/WICKET-5810 for the
experimental concept of a singleton page which you could use to implement
your server token solution. The singleton concept would even cover the case
where the user has the same form open in two windows and does the bad
thing. I would not want to depend on JavaScript for double submit
prevention. I have seen in production duplicate orders with JavaScript
prevention.

Regards,

Bernard