CSC/ECE 517 Fall 2009/wiki2 3 pp

Double Submit Problem

What is the requirement of having this pattern. Some examples such as Add to cart being pressed twice can result in 2 items in the cart etc. The example should provide or demonstrate how devastating this can be. Some financial example such as clicking on Pay button twice could charge credit card twice etc.

Solutions for Double Submit Problem

Can be server side or client side. Server Vs Client which one is better?

Client Side Solution - Javascript Control Disabling

Briefly describe the approach. Discuss pros and cons.

POST-REDIRECT-GET

Briefly describe the approach. Discuss pros and cons.

Synchronizer Token Pattern

How the patten works? Diagrammatic Representation? Theoretical View? Reply on session.

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

Implementations of the pattern provided by various frameworks

The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe how the built in support for synchronizer token is provided by various frameworks.

Struts

Apache Struts provides built in mechanism for handling tokens in org.apache.struts.action.Action class using the saveToken() and isTokenValid() methods. saveToken() method creates a token (a unique string) and saves that in the user's current session, while isTokenValid() checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an Action. Before loading the JSP call saveToken() to save the token in the user session. When the form is submitted, check the token against that in the session by calling isTokenValid(), as shown in the following code snippet:

class PurchaseOrderAction extends DispatchAction { 
      public ActionForward load(ActionMapping mapping,
                                ActionForm form,
                                HttpServletRequest request,
                                HttpServletResponse response) throws Exception {
         try {
             //save the token
             saveToken(request)
             // rest of the code for loading the form
         } catch(Exception ex){
             //exception
         }
      }

      public ActionForward submitOrder(ActionMapping mapping,
                                       ActionForm form,
                                       HttpServletRequest request,
                                       HttpServletResponse response) throws Exception {
          try {
              // check the token. Proceed only if token is valid
              if(isTokenValid(request,true)) {
                  //implement order submit functionality here
              } else {
                  return mapping.findForward("failure");
              }
          } catch(Exception ex){
              //exception
          }
     }
}

This actually what is happening behind the scene in the Action class. saveToken() has logic as below:

HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
   session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}

The method generates a random token using session id, current time and a MessageDigest and stores it in the session using a key name org.apache.struts.action.TOKEN (This is the value of the static variable TRANSACTION_TOKEN_KEY in org.apache.struts.Globals class).

The Action class that renders the form (PurchaseOrderAction.load) invokes the saveToken() method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>" 
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">

The embedded <bean:write> tag shown above, looks for a bean named org.apache.struts.action.TOKEN (which is the value of Globals.TRANSACTION_TOKEN_KEY) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is org.apache.struts.taglib.html.TOKEN (This is nothing but the value of the static variable TOKEN_KEY in the class org.apache.struts.taglib.html.Constants).

When the client submits the form, the hidden field is also submitted. In the Action that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the Action that rendered the form), the token in the form submission is compared with the token in the session by using the isTokenValid() method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the isTokenValid() method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using JavaScript hacks) but to handle the token intelligently. This is where the reset parameter is useful. The token is initially set before showing the first page of the form. The reset parameter is false for all the boolean) isTokenValid() invocations except in the Action for the last page. The last page uses a true value for the reset argument and hence the token is reset in the isTokenValid() method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Although the above approach is good, it requires application developer to add the token checking method pair – saveToken() and isTokenValid() in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different Actions, the pairs need to be identified and added manually. Next framework provides automatic support for generating and checking token thus developer do not have to worry about forming the pairs.

Spring Web Flow

Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called flows. A flow is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:

Figure 1 Spring Web Flow flow definition.

Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The POST-REDIRECT-GET idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a flow execution repository to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

Figure 2 FlowExecutionRepository Interface.

Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements FlowExecutionRepository interface.

• Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using generateKey(flowExecution), a new FlowExecutionKey will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. FlowExecutionKey objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using parseFlowExecutionKey(encodedKey), you can unmarshal a string form of a flow execution key back into its object form.

• Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a FlowExecutionLock. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.

• Line 15: Finally, the FlowExecutionRepository interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.

Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

       <flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:

       <bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
           <property name="definitionLocator" ref="flowRegistry"/>
           <property name="repositoryType" value="SIMPLE"/>
       </bean>

Figure 3 FlowExecutionRepository Class Diagram.

Simple Repository

Figure 4 Simple Repository.

The simplest FlowExecutionRepository implementation shipped with Spring Web Flow is, not surprisingly, called SimpleFlowExecutionRepository. It manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.

This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits.
Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.

Single Key Repository

The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository). When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

      http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments. While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

The Continuation Repository

The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the ContinuationFlowExecutionRepository class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation. Spring Web Flow’s continuation repository will use such web continuations to allow the application to behave correctly when the user opens multiple windows on a single flow execution or uses the browser’s Back button. Essentially, the continuation repository will take a snapshot of the FlowExecution sobject at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Below figure shows this graphically.

1. The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
2. The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
3. The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:

     flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>

1. The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the FlowExecutorFactoryBean). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

     <flow:executor id="flowExecutor" registry-ref="flowRegistry">
     <flow:repository type="continuation" max-continuations="5"/>
     </flow:executor>

The same configuration using classic Spring bean definitions follows:

     <bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
         <property name="repositoryType" value="CONTINUATION"/>
         <property name="maxContinuations" value="5"/>
     </bean>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a denial of service attack by generating a large amount of snapshots.

References

[1] References go here