Announcement Announcement Module
Collapse
No announcement yet.
Double submit Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Double submit

    Please tell me what all I have to do to prevent double submit. I am not getting any good article.

    Thanks in advance

    Best Rgds - ssroy

  • #2
    Double submit problems usually cover 2 different scenarios. Which of these two are you concerned about?

    1. User submits a form. User presses the browser back button, and submits the form again. (alternatively, user simply refreshes the page, which could cause another form submit)

    2. User clicks on the submit button twice (or more) rapidly, causing multiple submits.
    Last edited by InverseFalcon; Feb 23rd, 2010, 06:55 PM.

    Comment


    • #3
      Thanks.

      I want to take care of all scenarios you have mentioned.


      Regards - ssroy

      Comment


      • #4
        #1 is taken care of by SWF. It uses the POST-REDIRECT-GET pattern, so when a page is rendered to the user, the URL is stable, and has no side effects if you should refresh it. If you want to prevent the user from even going back to the previous page (or beyond) and submitting again, you can discard or invalidate the history (saved snapshots of state). You can do this with the "history" attribute of the transition away from the sensitive state:

        Code:
        <transition on="whatever" to="wherever" history="invalidate"/>
        This thread might also be helpful, in terms of dealing with exceptions when you use the browser back button after history has been invalidated.

        As for #2, you can either use javascript to disable the button or form on submission, or you can use some kind of token mechanism which will only accept and process the first submission.

        I don't think SWF has built in support for this (someone correct me if I'm wrong), but you should be able to implement it yourself with the UUID class (in Java.util for Java 5 and higher) to get a random UUID (your token), and a FlowExecutionListenerAdapter (you'll need to add it to your flow config), overriding the viewRendering() to create and add your token to whichever scopes you need (view and request, I think) and resuming() or transitionExecuting() to compare the tokens on a submit. Of course, you'll need to add the token's long value to any forms you want as a hidden form parameter. It might also help to only perform this token check if your transition has a custom attribute to signal that a token check should be performed for the transition to succeed.

        As a bonus, the token implementation will probably give you some protection against XSS attacks.
        Last edited by InverseFalcon; Feb 24th, 2010, 02:26 PM. Reason: request scope is probably a better scope than flash for saving the token

        Comment


        • #5
          Thank you very much for the response.

          Best Regards,

          ssroy

          Comment


          • #6
            Hi,

            1) I have implemented as you have suggested and it worked. But what I observed is, exception in the Filter class gets caught in Exception block and not in 'FlowExecutionRestorationFailureException' block which should be case.

            2) Regarding XSS: I observed that without doing anything web flow is taking care of this point. In text input box, I entered

            <script>alert('1')</script>

            and in the confirmation screen value was displayed as is and no popup. Am I missing anything.

            Thanks & Regards - ssroy

            Comment


            • #7
              Right, forgot to mention that SWF likes to wrap its exceptions. I'm also catching Exception, then checking to see if its cause is a FlowExecutionRestorationFailureException. I think that should work for you.

              Whoops, I meant CSRF protection, not XSS. When each form submission requires a unique, request-specific token, most CSRF attacks fail. SWF's flow execution ID provides some protection in this area, but the execution and snapshot numbers increment predictably, and are considered valid for as long as the snapshot is around, so a token mechanism is stronger.

              Comment


              • #8
                ok. Thank you very much for the response.

                Best Regards,

                ssroy

                Comment

                Working...
                X