Ravi, your Pseudo-code is almost perfect, but there is a little bug there. In the step 3, you have to remove the else statement where you save the token again. If you do that, this can happen:
1. user hits the load action and save the token 2. user hits the save action and the token is reset 3. user hits back button in the browser 4. user submits again, hits the save action, the token is not valid and it's set again(because of that else) 5. user hits back button in the browser for the second time 6. user submits again the form, hits the save action, and guess what? the token is valid and the data is submitted again.
How will this work if the design is such that the same action class acts as both the PreActino and PostAction class?
I have a page which does have a PreAction action and when the user submits the form the postAction class is called but the user is returned back to the same page meaning that they are allowed to make further changes to the same form and thus calling the postAction class without going through the preAction class.
First of all thank you for letting me know this pattern.
O. Ziggy :
I think the flow would be as follows :
1) User comes through pre-action class on jsp page.
2) Now tocken has been saved and should be visible on jsp page.
3)User fills-in the form and submits it.
4)post-action class is called and as a valid tocken is found in it ,flow comes in if part.
5)tocken is reset
but user has entered some invalid data, or there there is some more info that is needed,
so he should be brought to form again to allow him to make changes.
In that case we will not reset the tocken
Now he is brought through post-action class instead of preaction class as Ziggy is suggesting.
5) so when user comes to post class for the second time tocken is not reset and is still valid which willl allow the user to submit the form again .
Also, I think there is no need to have that else part. Instead the code segment should look like this as follows :
We just implemented this in an application I am working on - but I have a doubt about our implementation (which is much like yours): shouldn't the calls to isTokenValid() and resetToken() execute within a synchronized block? Otherwise, I could see two clients issue request that would get processed such that the first client would execute isTokenValid(), get a true result then get interrupted to have the second client's thread execute. In such a scenario, wouldn't they both process the request "in parallel" ?
Or alternatively, call isTokenValid(request,true), which would have this call automatically reset the token, if it was valid, before it returns...
subject: Duplicate form submission - Synchronizer Token Pattern