CSC/ECE 517 Fall 2009/wiki2 3 pp: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 23: Line 23:


=<font color="windowtext">Implementations of the pattern provided by various frameworks</font>=
=<font color="windowtext">Implementations of the pattern provided by various frameworks</font>=
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.


==<span class="apple-style-span"><span style="mso-bidi-font-size: 12.0pt; line-height: 115%"><font color="windowtext">Struts</font></span></span>==
==<span class="apple-style-span"><span style="mso-bidi-font-size: 12.0pt; line-height: 115%"><font color="windowtext">Struts</font></span></span>==

Revision as of 05:38, 7 October 2009

Synchronizer Token Pattern - Introduction

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

Spring Web Flow

Ruby on the Rails

Grails

References

[1] References go here