> At first I thought you were pulling a Friday funny on me.
>
> But I do see your point, having properly read your post now.
>
> I think, in our case, the web form is a very long way away from the database,
> and after submission
> we go through a few human workflow steps involving assessing and validating
> the submissions
> before it gets anywhere near our DB, so I might just stick with JavaScript
> for the moment.
> Double-submission is more of an annoyance than a peril in our situation.
>
> Here's what I've gone with (because I lurve C# and hate JavaScript)
>
> btnSubmit.Attributes.Add("onclick", "this.disabled=true;");
>
> in the form OnLoad.
Please don't do this. The most obvious reason is that if someone
presses escape while the form is loading it's still stuck. There are
more reasons (it doesn't work if JavaScript doesn't work, and so on).
My current approach, is, assuming you allow sessions, a token in the
page. You set the token on load, and in the session. When the page is
posted, you check that the last submitted token matches the next
expected token. If it doesn't match, it's a double-submit (or,
significantly less likely, could indicate a CSRF attack
(http://en.wikipedia.org/wiki/Cross-site_request_forgery)). If it does
match, immediately set the next token to be a new token, and then
carry on processing.
Microsoft's MVC framework has an inbuilt approach to this, described
here (first link I found:
http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/)
> Dylan.
--
silky
Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature.
