• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Duplicate form submission - Synchronizer Token Pattern

 
Ranch Hand
Posts: 389
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi

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.

Pseudo-code:


Step 2: MyPage pseudo-code


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

Step 3: SubmitAction


Thanks

-- Ravi
[ July 15, 2005: Message edited by: Ravindra Janapareddy ]
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Regards,
Lucian

PS: Anyway, your example was very helpful for me
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.
 
Ranch Hand
Posts: 430
Android VI Editor Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

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.

Ta
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 :

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!

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

Moises
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic