To the authors of the book. Questions about the Synchonizer Token
Hi guys,
a few questions about the Synchonizer Token (page 77 --> 82).
When a page (that souldn't be submitted more than once) is requested, a unique value is generated. That value is included in the page (hidden field) as well as in the user's session object. When the page is submitted, the controller checks wether the two values match. Ok. But you don't indicate when (and where) the value in the session should be changed (or removed?). If the user uses the back button to submit again the form, the two values will match again !!
Thanks for your help.
[618 byte] By [
javamad] at [2007-9-26 3:07:44]
Hi, when staring to process the request, the Synchronizer Token will (should) be changed to a new value.I am not a author of the book (Core J2EE Patterns - that's what you're talking about?!) but i think that's the way it's to be done.
Hi,
> Hi guys,
>
>
> a few questions about the Synchonizer Token (page
> page 77 --> 82).
As someone has already correctly pointed out, the token value is reset after the current values are checked for a match and before the view is generated the current request.
Figure 5.3, Synchronizer Token Lifecycle, on page 78 was intended to communicate this information. It shows that the incoming request goes through the following flow:
Compare Values --> Process Request --> Generate Token --> Store Token --> Prepare Response
(BTW, your copy may have 'Share Token' instead of 'Store Token', b/c there was a typo in early versions of this image)
The 'Generate Token' point of the lifecycle is where the new token value is generated each time. The 'Store Token' point of the lifecycle is where the token value is stored/reset.
Hope this helps.
Dan
>
>
> When a page (that souldn't be submitted more than
> once) is requested, a unique value is generated. That
> value is included in the page (hidden field) as well
> as in the user's session object. When the page is
> submitted, the controller checks wether the two values
> match. Ok. But you don't indicate when (and where) the
> value in the session should be changed (or removed?).
> If the user uses the back button to submit again the
> form, the two values will match again !!
>
>
> Thanks for your help.
Hi Dan,
thanks for your answer. I've a remark now :
For me, the value should ONLY be added in the user's session!
1 the page containing the form is requested for the first time. You add the unique value (UV) in the session object.
2 the page is submitted. In the controller you check wether there is a UV in the session object.
- if there is something, just remove it from the session and forward to the result page
- if there is nothing, this is a duplicated form!! Just forward to the error page...
Am i wrong somewhere ?
Thanks for your help.
The suggested approach...
Compare Values --> Process Request --> Generate Token --> Store Token --> Prepare Response
does have a weakness when the time to "Process Request" takes a significant amount of time. A browser can break the synchronisation by pressing, for example, a save button twice in quick succession.
To minimise this window of potential failure I am actually implementing the following...
Compare Values --> Generate Token --> Store Token --> Process Request --> Prepare Response
