wood burning stoves
The moose likes Struts and the fly likes Duplicate form submission - Synchronizer Token Pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "Duplicate form submission - Synchronizer Token Pattern" Watch "Duplicate form submission - Synchronizer Token Pattern" New topic

Duplicate form submission - Synchronizer Token Pattern

ravi janap
Ranch Hand

Joined: Nov 04, 2000
Posts: 389

I have provided here simple steps needed to implement synchronizer token pattern for the benefit of the readers.

Avoid duplicate form submission using Synchronizer Token Pattern in a STRUTS-based application

How to prevent a duplicate form submission on a Struts JSP page. The duplicate form submission can occur for any of the following reasons:

(a) When a user clicks more than once on a submit button before the response is sent back

(b) When a client clicks on the Back button in the browser or simply refreshes the pages

(c) When the user accesses the web page by returning to a previously bookmarked page.

A typical STRUTS based implementation for a JSP page consists of the following components:

(a) DisplayAction executed before the JSP page �MyPage� is displayed.

(b) The JSP page �MyPage� containing form fields and a submit button

(c) SubmitAction executed as a result of clicking submit on MyPage JSP page.

Follow these simple steps:

Step 1: DisplayAction

Call saveToken(request): Puts the Token in the session. It also get puts in the request as a hidden form field by the Struts <html:form> tag if the Token is found in the session.


Step 2: MyPage pseudo-code

Do a right click with your mouse in the browser and search for the hidden fields.

Step 3: SubmitAction


-- Ravi
[ July 15, 2005: Message edited by: Ravindra Janapareddy ]

Lucian Ochian

Joined: Nov 23, 2004
Posts: 7
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.


PS: Anyway, your example was very helpful for me
steph thomas

Joined: Mar 05, 2009
Posts: 1

I have implemented this pattern (Synchronizer Token ) as above and it works well on my jsp. When I hit the back button it doesn't give me any errors and the user can continue filling out the form.

The issue that I am now encountering is that I have added to my jsp:
enctype="multipart/form-data" to my <html:form > for the <html:file > for attachments to work.

When I am now testing the back button, I am getting an error: webpage expired. I believe that it's due to the encryption type and the form is being submitted differently than before.

Is there any way around this?

At the end of the day. I just need to have the back button disabled and still able to upload files.
O. Ziggy
Ranch Hand

Joined: Oct 02, 2005
Posts: 430


On this line

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.

Shailesh Vaishampayan

Joined: Sep 19, 2010
Posts: 2
Hi All,

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 :

Moises Lejter

Joined: Aug 10, 2006
Posts: 3

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...

I agree. Here's the link: http://aspose.com/file-tools
subject: Duplicate form submission - Synchronizer Token Pattern
jQuery in Action, 3rd edition