http://www.perlmonks.org?node_id=1043063

gayu_justin has asked for the wisdom of the Perl Monks concerning the following question:

helo, my problem is that, i have a form using in a template file and action to a cgi page.But whenever i refresh the page, the the entered values are getting inserted again.How can i prevent this ????

Following is the code using in the template file.
<body > <form name="group" method="post" action="process.cgi"> <div id="mainContainer"> <div><label>Group name : </label><input type= +"text" name= "group_save0"> <label>Group description : </label><input typ +e="text" name= "group_save1"> </div> </div> <div><input type = "submit" name ="firstsave" +value = "Save"></div> </form> </body>
following is the code in the cgi page.
if ($grupsave1 ne '') { if ($grupsave1 =~ /^([-\@\w\s.]+)$/) { $grupsave1 = $1; print $grupsave1; } else { die "Bad data for group name('$grupsave1') in group"; } if ($grupsave2 =~ /^([-\@\w\s.]+)$/) { $grupsave2 = $1; print $grupsave2; } else { die "Bad data for group description('$grupsave2') in g +roup"; } my $grupsave_insert = $dbh->do (q{INSERT INTO group_management (group_ +name,group_description,isactive) VALUES (?,?,?)}, undef, ($grupsave1, +$grupsave2,'y')); } else { }

Replies are listed 'Best First'.
Re: How to prevent a Reload from resubmitting a form?
by rjt (Curate) on Jul 08, 2013 at 11:14 UTC
    But whenever i refresh the page, the the entered values are getting inserted again.How can i prevent this ????

    Your form is set up with an HTTP POST handler. Per RFC 2616, POST requests may be non-idempotent (i.e., their processing can affect changes on the server, such as inserting a row into a database). For this reason, browsers (by default) force the user to confirm their intention to re-submit their request with a very conspicuous pop-up.

    GET requests, on the other hand, can (in theory) be re-submitted all day long with no change. In practice, however, there is nothing preventing CGI developers from having their GET requests do most of the same things POST requests can, and it's not that uncommon, either. So don't think that switching over to GET will solve your issue.

    More to the point, this problem tends to be solved through some combination of Javascript (not always) and a form ID hidden field generated by the server and embedded into the <form> HTML code. The server-side (CGI) code keeps track of these IDs (in RAM, database, whatever), and gracefully rejects any further submissions after the first POST is received. Depending on what the form is for, you can decide whether you'll give the user the option of submitting it anyway, or just throw a big fat error message in their face.

    This is not a very Perl-ish response, because while you did have a Perl CGI, the root issue really comes down to a better understanding of CGI. To that end, have a gander at http://www.w3schools.com/, POST (Wikipedia), and useCGI; for a decent head start.

Re: How to prevent a Reload from resubmitting a form?
by Ralesk (Pilgrim) on Jul 08, 2013 at 11:20 UTC

    By, rather than rendering an entire page as a response to the POST request, redirecting the user to another page where they can — for example — see the result of their query.

    This way, the page they end up opening will be served by a GET request, which can be freely reloaded any time.


    It is worth mentioning that you have resubmitted this question several times because of this very issue — and PerlMonks serving entire pages as results of POST requests.

Re: How to prevent a Reload from resubmitting a form? (P/R/G)
by Anonymous Monk on Jul 08, 2013 at 11:25 UTC
Re: How to prevent a Reload from resubmitting a form?
by sundialsvc4 (Abbot) on Jul 08, 2013 at 14:13 UTC

    ... but if your server is even slightly slow, impatient users WILL mash the stop-button and resubmit or reload your page.   You have to be prepared for whatever happens, on the server side. nbsp; Anything that happens, can happen at any time, and can happen again, and there is nothing you on the server side can do about it.

    However, there are various ways to detect it.   One way, which is often used anyway to avoid CSRF attacks, is to include a hidden field on the form which contains a pseudo-random string.   You save that value in the host-side session store before sending the page.   When a reply comes back, that identical string should still be there, and you should be seeing it for the first time.   If you don’t, then you know that the data is either “stale” or resubmitted or a forgery.   (I have also seen sequence-numbers and server-side Unix timestamps in hidden fields.)   But, you, in your server-side programming, must either do this, or be using a framework that does this for you, because the user-side can do whatever it wants, whenever it wants, rightly or wrongly.   This, BTW, is true of every web programming language, since it is inherent in the design of HTTP.   Even Javascript tricks designed to suppress multiple-mashes can be circumvented if the user successfully reloads the page, and you have to assume that, somehow, that’s what he managed to do.