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