Win a copy of Spring Boot in Practice this week in the Spring forum!
  • 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
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

How good is PRG (POST/REDIRECT/GET) pattern in avoiding duplicate form submission?

 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello fellow ranchers,

I was reading through PRG Pattern for avoiding the duplicate form submission and wanted to get some practical advantages, disadvantages of this pattern, if any body has used it. From the diagrams that were given in the post, I see that duplicate submission can be avoided, if the duplicate submission is made during/after redirect is done. But how about a duplicate submission that happens, even before a redirect is initiated.

What are the other ways to avoid duplicate submission. Some of the solutions, which I saw, implemented are as follows

1) disabling the submit button, but a back button would enable it.
2) Using a flag for the entire session, based on which the button is enabled/disabled.
3) Verification and comparision of the data that is being submitted to the already existing one. This is absolutely inefficient in most real time cases, as it increases the time complexity. But still a solution, though not an efficient.


Can some one give me more possible solutions, that can be implemented and how can PRG be leveraged.

[edit by Roberto Perillo: changing POST/REDIRECT/GOOD in the subject to POST/REDIRECT/GET to avoid misunderstandings]
 
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There's the Synchronizer Token pattern which is a core JavaEE pattern, and implemented by popular MVC frameworks like Struts.
Briefly, a token t1 is generated, stored in session, and included in the JSP <form>.
When user submits form, the servlet/action/controller checks that the token it got in the POST request matches the one in its session.
If it matches, it resets the token to a new value t2, and proceeds to complete the request.

Now if user presses submit again, the form contains t1 but the session already has t2. Abort the request.
If user presses Back after the PRG, assuming browser has cached the page, the page will again contain t1. Abort the request.
If user presses Refresh after the PRG, page will now contain new token t2 and the request will go through.

I use combination of disabling button (javascript) and sync token provided by the framework.
 
Sheriff
Posts: 67651
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
PRG = Post/Redirect/Get
 
Ravi C Kota
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bear Bibeault wrote:PRG = Post/Redirect/Get



Yes, It was a typo.... too quick on my keyboard... I apologize.
 
Ravi C Kota
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Karthik Shiraly wrote:There's the Synchronizer Token pattern which is a core JavaEE pattern, and implemented by popular MVC frameworks like Struts.
Briefly, a token t1 is generated, stored in session, and included in the JSP <form>.
When user submits form, the servlet/action/controller checks that the token it got in the POST request matches the one in its session.
If it matches, it resets the token to a new value t2, and proceeds to complete the request.

Now if user presses submit again, the form contains t1 but the session already has t2. Abort the request.
If user presses Back after the PRG, assuming browser has cached the page, the page will again contain t1. Abort the request.
If user presses Refresh after the PRG, page will now contain new token t2 and the request will go through.

I use combination of disabling button (javascript) and sync token provided by the framework.



Thanks Karthik
 
Ranch Hand
Posts: 222
Google Web Toolkit Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I always thought of this pattern as something that should be normally done to comply with MVC 2. So is it a different pattern or some kind of "subpattern" of MVC 2?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic