Investigate implications of multiple posts

Tony, do you have any example of this? I don't think there's a single website that would even attempt to protect against this, there's just no way to determine whether something is a duplicate postback or not. All browsers already have their own check if you attempt to post something back that's already been posted, but ultimately I can't think of a reason to stop them anyway.

I found out about this when I accidentally hit the Create schedule button twice - generates duplicate schedules - which for reference are safe in terms of the uniqueness of their timing ids.

Reassigned for confirmation

Additionally, there is a way of protecting against that specific problem (if it is a problem) - if the timing guid is generated on the GET controller action, and subsequently sent through to the POST action (and sent through again if validation etc. fails), then all multiple POSTs will do is force a 'timing already exists' engine exception.

Well I don't think we should be generating IDs on the GET before the POST, but that's a separate issue for later.

Regarding the particular scenario you talked about, are there separate methods for creating and updating timings? If so, then I would expect that it already checks if you're trying to create a timing with a duplicate ID.

It does check, but a key is randomly generated on the POST action.

Which is what I would expect - so all it will do is create a second, identical timing with a different id? That's the expected behaviour and I'm not sure what else we could do here.

I've seen sites that disable the button onClick.

Is that or a comment or a suggestion? I don't really like the idea of that, I think we're imposing a problem where there isn't one.

Any comments Adam? Not sure what to do with this in its current state.

Possibilities:

1. Do nothing - Is this really going to be a problem? Is providing this fix going to cause more problems than it's worth?
2. Create a JavaScript onClick function on the submit button that sets itself to disabled.

Both are easy, I'm inclined to go with option 1 until it becomes a problem. And we at least have a record of a possible course of action.

Agree on the "won't fix" for now.