CSC/ECE 517 Fall 2009/wiki2 3 b5: Difference between revisions
Chump Chief (talk | contribs) |
Chump Chief (talk | contribs) |
||
| Line 6: | Line 6: | ||
== Overview == | == Overview == | ||
The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again. | |||
== Example application == | == Example application == | ||
Revision as of 00:54, 10 October 2009
Synchronizer Token Pattern
Problem summary
Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.
Overview
The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.