Why PRG pattern rather than others?
Asked Answered
S

1

6

I need to prevent duplicate form submissions for my customer's website.

  • we need some form data from user for order confirm page.
  • we use load balancing for web server.

Approach 1 : Post/Redirect/Get

(PRG pattern : http://en.wikipedia.org/wiki/Post/Redirect/Get) Post/Redirect/Get

I was trying to use PRG pattern at first.
in this case, I think I need to deal with session(or spring flashmap) across multiple web server.

Approach 2 : Disable refresh on client.

Disable refresh on client

one of my colleague suggested this approach.

Approach 3 : Post/Post

Post/Post

another colleague suggested this approach.

I think approach 2, 3 is not a good choice.
but I do not know the specific cons or security risk about these approaches.
I tried to google, but I failed to find answer.

Thank you in advance.

[Edit]

I would like to update the pros and cons.

Approach 1 : Post/Redirect/Get

pros

  • Safe!

cons

  • if you need some form data from user to show it on confirm page, you need to use session ,database or something.
  • if you use session, and have more than one server, you have to do something to make session available across multiple servers.

Approach 2 : Disable refresh on client.

pros

cons

  • Users will get upset if you limit the browser standard features, like refresh.
  • need to consider F5, Ctrl+F5, ⌘ + F5 etc, various refresh icons.
  • In mobile, many web browser automatically refresh page when user reload browser.

Approach 3 : Post/Post

pros

  • You don't have to worry about session sharing issue across multiple servers.

cons

  • Second form submit can fail.
Sundry answered 10/1, 2015 at 8:18 Comment(0)
C
6

Approach 1 is a pretty straight forward method that solves some duplicate post issues. It won't cope with server lag and which is a reason for duplicate submission.

Approach 2 is nothing but wrong. Users will get upset if you limit the browser standard features, like refresh. That is, if you are even able to do so technically cross browser. You need to consider F5, Ctrl+F5, ⌘ + F5 etc, various refresh icons.

I must admit that I don't fully understand the intent of Approach 3, however, it feels a bit wrong to bounce the user to an empty page.

Another standard approach is to use a nounce with form posts. This will also help you avoid a security risk called Cross Site Request Forgery. It's pretty simple.

  1. Generate a "unique" random string on the server, called nonce.
  2. Insert the nonce into the database.
  3. Attach the nonce to the form as a hidden field (or pass by URL or similar).
  4. Make sure the nonce is sent along in the form post to server.
  5. At server side, validate the nonce, remove nonce, "save form data".
  6. Display confirmation page.

If you get another request with a non existing nonce, then you know it's either a duplicate post or some more evil CSRF attack.

You can probably find some support library that does this for you.

Cooperate answered 10/1, 2015 at 8:51 Comment(5)
the intent of approach 3, as I said, we need some form data from user (e.g. the color that user chose) and need to show that on confirm page.Sundry
in PRG pattern, we can use session. but as we use multiple web servers, session sharing or something is an extra job to do.Sundry
and we can use parameter when we redirect, but I think it's not good idea showing user's order data in url.Sundry
so, to send 'user form data' from submit page to confirm page easily, my colleague suggested approach 3.Sundry
Ok, the nonce approach does not rely on shared sessions - it relies on a shared database which I guess you already have.Cooperate

© 2022 - 2024 — McMap. All rights reserved.