Article on double-response protection

Discussions

News: Article on double-response protection

  1. Article on double-response protection (18 messages)

    One of the problems servlet authors often have to deal with is double-submit, where someone posts a response that modifies data more than once (causing multiple updates, potentially.) Fingo.com has published an article detailing their response cache filter, part of an open source utility project.
    Double requests can have a serious negative impact on the application. Let's imagine double shop cart confirmation. In the worst case the user’s account can be charged twice (or even more, if there are more clicks on the submit button). In cases of database insert operations, double actions can duplicate data. Because after double clicking both requests are processed concurrently for the same user session, this can lead to unpredicted interactions in business logic or cause database constraint violation. Refreshing the last page can have nearly the same negative effects that double clicking has. However, because the actions are executed one after another, they are more predictable and easier to manage. Use of the back button can disturb the process of long running transactions if applications have to have a strict action sequence. Receiving a request which has been handled four steps before can damage the application state if it hasn't been designed for such a situation.
    Many frameworks already have some support for double-submit protection, such as Tapestry and Webwork. If you're not using such a framework, solutions like this might be well worth looking into.

    Threaded Messages (18)

  2. Hmmm ...[ Go to top ]

    Sometimes I just use JavaScript disable a button after it's been clicked. It's ain't real smart or nuthin' but it seems to work OK :-?
  3. Re: Hmmm ...[ Go to top ]

    This is also my preferred way. Disabling submit button plus RGP pattern may be the best combination for web apps.
  4. PRG Pattern[ Go to top ]

    There is already a pattern to handle this problem without adding additional layers of complexity to your solution. Web based UI's should simply follow some basic rules: 1. HTTP POST should be used when you intend to change server state 2. HTTP GET should NEVER EVER EVER EVER change server state. It should only be used to fetch the view. 3. After a POST, you should send a redirect to "GET" the view. You should never render a view as a response to POST. This pattern elegantly solves many problems associated with the back and refresh buttons on your web browser. There is even a great article on PRG in the TSS archives somewhere.
  5. Re: PRG Pattern[ Go to top ]

    AGREE mostly. The only state update for GET requests is for counter increment, if needed.
  6. Re: PRG Pattern[ Go to top ]

    I think it is good practice to disable the submit button in addition to the PRG pattern. If the redirect takes a long time to reach the browsers you can sometimes click submit again.
  7. Re: PRG Pattern[ Go to top ]

    Exactly. But users very often turn off javascript. The solution described in this article always works.
  8. Re: PRG Pattern[ Go to top ]

    Exactly. But users very often turn off javascript.
    The solution described in this article always works.
    I think this is an urban myth. Does anyone have any hard numbers as to the % of users that turn JS off?
  9. Re: PRG Pattern[ Go to top ]

    Exactly. But users very often turn off javascript.
    The solution described in this article always works.


    I think this is an urban myth. Does anyone have any hard numbers as to the % of users that turn JS off?
    I so agree. The people with JS turned off will have very limited success in surfing the www of today. Also, how about "all those users" which has Cookies disabled... Hard numbers anyone?
  10. Re: PRG Pattern[ Go to top ]

    http://www.w3schools.com/browsers/browsers_stats.asp seems to indicate that 10% of users have JS disabled. Personally I use the Firefox NoScript plugin (which has over 100k downloads) which lets me pick and choose whose javascript to permit. So unless a site requires javascript before I get to the point of form submission, I'd still be able to double-submit. For a lot of forms this doesn't matter, but any time there's money involved I would hope that something more robust than javascript button disabling is in place.
  11. Re: PRG Pattern[ Go to top ]

    http://www.w3schools.com/browsers/browsers_stats.asp seems to indicate that 10% of users have JS disabled.

    Personally I use the Firefox NoScript plugin (which has over 100k downloads) which lets me pick and choose whose javascript to permit. So unless a site requires javascript before I get to the point of form submission, I'd still be able to double-submit. For a lot of forms this doesn't matter, but any time there's money involved I would hope that something more robust than javascript button disabling is in place.
    Most shopping applications store shopping cart in the session scope. In this case protection is very simple: insert the items into database then immediately dispose the cart. Trying to resend the same request will yield to nothing since the cart has been already deleted. No cart, no insert. Another way is to assign a unique number to the cart, then use this number as PK in the database. Database will deny a duplicate insert, this is simple and does not depend on application interface be it a web application, a web service or a traditional desktop application.
  12. NoScript[ Go to top ]

    Exactly. But users very often turn off javascript.
    The solution described in this article always works.


    I think this is an urban myth. Does anyone have any hard numbers as to the % of users that turn JS off?
    No good numbers, but if you take a look at the top firefox plugin, NoScript comes in 2nd behind flasget. I personally have NoScript turned on and disable all javascript by default. If we are talking about a webapp used in an internal LAN, sure most users or I.S. wouldnt disable Javascript. However in some environment (think corporate personnels in a bank), where not only public internet access is limited to privilege users but there are very strict rules to follow (i.e. disabling things that may potentially cause a compromise to the internal network, this includes javascript). I was in this environment (used to be a sysadmin at a bank). Most of the sysadmins and managers were considered to have the privilege of such access. Now if you count the number of people for one single bank, it may not be alot. But if you consider all banks/branches for all countries in the world, thats a lot of users assuming you are running a publicly accessible site like amazon, ebay, etc.
  13. Re: PRG Pattern[ Go to top ]

    sorry, it does not work in all cases. Firefox sometimes sends form data again, if user is using scroll button on mouse. I use this pattern too (redirect to GET after POST), but some users generates double posts. After some investigation we found that some firefox browsers are confifured this way :-(
  14. Re: PRG Pattern[ Go to top ]

    RPG pattern solves the "Refresh" problem. JavaScript can solve the "Refresh", "Back" and "Double Click" problems. The solution may be different for dirfferent browsers. Token solves the "Refresh", "Back" and "Double Click" problem, but the error page for invalidate token is not user friendly. The posted method gives user friendly page. I like it.
  15. Re: PRG Pattern[ Go to top ]

    The posted method gives user friendly page. I like it.
    Developer-friendly -- yes, user-friendly -- hardly. It would be user-friendly if it could have avoided the POSTDATA dialog, which is not possible because POSTDATA dialog is automatically displayed by browser for POST requests.
  16. Missing information[ Go to top ]

    The article lacks some important points IMHO. It should explain how and when the cache is cleaned up, because storing all the complete responses of all the requests of all user sessions in a cache seems like a pretty high risk for the scalability of the webapp to me. And I don't even mention the case of a webapp that returns images or documents in addition to HTML text. Limiting this technique to well-identified non-idempotent POST requests would certainly be a good idea. BTW, it also doesn't explain how to deal with intentional double submits (for example, if I add the same article twice in my shopping cart intentionally).
  17. Another issue is that the "first meaningful response" returned to a double-submit or backbutton will show the application state at some point in the past. If the response contains time sensitive data, such as the latest post, or workflow state, then this will be incorrect. So you should be a bit choosey as to when to use this technique.
  18. I agree. I'm personnally in favor of the redirect-after-post pattern, and of a manual "transaction token" management à la Struts, with an error message in case of a double submit. At least, if the message is meaningful and clear enough, it has a chance of educating the users on how to use webapps.
  19. ever hear of a save token?[ Go to top ]

    ? sorry thats like 5 years old