Home » none » The "Double Submit" Issue from the Server Side

The "Double Submit" Issue from the Server Side

food-deli-015 There are many times when you might want to ensure that a user only submits information to your system once.  The most common, of course, is when you are collecting credit card information for a purchase.  But there are other times as well.

The most common way of dealing with this is by using JavaScript to disable the submit button.  Since most people using the web have JavaScript enabled, this works 99% of the time.  But there are people who are so paranoid that they have turned off JavaScript and there are people browsing now with hand held devices that don’t support JavaScript (yet).  This means we must also protect ourselves from the double submit issue on the server side.

I first had this issue a few years ago on an application that people filled out to determine their chances of getting into the top 100 colleges and universities in the country.  We didn’t want to charge people twice for the information.  Since we could be pretty sure that the same person would not be filling out two forms at he same time, we simply set a session variable to "YES" and checked it before billing them.  But an even more foolproof system would be to hash the data they are buying and store that in the session variable.

Here is some sample code:

string yourDataHere =
    "your data needs to be built up as a string";
string hashedData =
    System.Web.Security.FormsAuthentication
    .HashPasswordForStoringInConfigFile
    (yourDataHere, "MD5");
if (Session[hashedData] == null)
{
    Session[hashedData] = "YES";
    // do the rest of your processing here.
}


And because Sessions are locked, you won’t even have to worry about a race condition.  The second post won’t even be processed until the first request completes.

See: Session State Uses Reader/Writer Lock

Like this Article? Subscribe to get every article sent to your email.

Related Post

  • What is .NET’s Object.GetHashCode() Used For?What is .NET’s Object.GetHashCode() Used For? Here is a great question from a visitor. “What is the exact use of GetHashCode of an object in .net? Does it have any relation with garbage collection?” Let's answer the second […]
  • ASP.NET Response.Redirect() and JavaScriptASP.NET Response.Redirect() and JavaScript Yesterday we covered issues surrounding using ASP.NET's Response.Redirect in server side code. We noted that not handing it correctly could prevent code from running on the server that we […]
  • Tracking down SQL Server Connection IssueTracking down SQL Server Connection Issue Same client as yesterday, but new problem. Today, they finally got the new parts they needed to get their SQL server back up and running.  Which was the main problem that caused […]
  • How to Excel as a Programmer (or anything else)How to Excel as a Programmer (or anything else) From a very early age we have been conditioned to fail. I know that probably seems harsh, and probably seems like an over generalization, but it is true. Here are some things you can […]
  • Catching Data for PerformanceCatching Data for Performance   I got a question the other day from a gentleman who is writing an application for YouTube.  His problem is that he's gathering data from the YouTube web site and redisplaying […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.

One Pingback/Trackback

  • Pingback: Dew Drop - December 18, 2008 | Alvin Ashcraft's Morning Dew()

  • Swizec

    Hashing doesn’t work on the most common double submit problem. That is when the user clicks submit multiple times before the page loads. This would mean that you get several POST requests all with the same data and none with the hash in the session since the forms were sent before session data had time to change.

    A better way would be to check the database for duplicates before adding new content. Or by putting time into a hidden form field, then having it as a key value in the database. If the user submits a form created at the same time more than once only first time counts, next produces a duplicate key error. Very sturdy.

  • Dave

    I fail to see the problem. The session variable will exist by the time the second post gets in. I’ve used this method successfully for years (and tested it). It is not some theory I just developed.

    IF you have a database, you method would work too. But it is no more reliable than what I proposed. Depending on the circumstance, you’d want to make sure the duplicate you were checking for included the Session ID so that you are only eliminating duplicates from the same user and not duplicates from any user.

    Personally, I like the session method because it quickly identifies the duplicate and means my code doesn’t have to do all of the other processing I would normally have to do prior to putting the information in the database. If I had a database, I’d probably also have duplicate key checks. It all depends on the actual problem behind the solution. This is a generic solution that handles any situation.
    ———————————————————————
    BTW, clicking on your URL caused my browser to crash (on multiple computers) so I removed it.

  • Mike

    are we talking asp.net session variables?

    Wont those get erased on an app pool recycle? Or even get mangled if the web app is running in a web farm?

  • http://swizec.com Swizec

    Oh, maybe it’s different in ASP then.

    And my URL shouldn’t be causing anything to crash, must’ve been your flash plugin because the front page currently holds a youtube video.

  • Dave

    Yes we are talking about ASP.NET session variables.

    Yes, they will get erased on an app pool recycle if you are using inproc sessions, but you should be using a session server of some type even on a single server, which will prevent that problem.

    On a web farm you woud also use a session server and no there will not be any issues because of the web farm. If there are, you haven’t set your farm up correctly.

    See: http://blog.dmbcllc.com/2008/01/14/the-case-of-the-disappearing-session-variables/ for a further discussion on inproc vs session servers.