Preventing multiple form submissions

[Matt]

I have an interactive web page that I need to prevent refreshes on.
The problem is that I want to ALLOW resubmissions, but only via the
submit button. My web page has two forms on it, one form for adding
users, and one form for removing users. I want to be able to add a
user, click the submit button, add another user, click the submit
button again, and so on, BUT, disallow adding a user and then hitting
refresh (which would add the same user again) Any ideas on how to do
this??

Thanks.

Matt Williams

[Chris Hope]

Matt wrote:

I have an interactive web page that I need to prevent refreshes on.
The problem is that I want to ALLOW resubmissions, but only via the
submit button. My web page has two forms on it, one form for adding
users, and one form for removing users. I want to be able to add a
user, click the submit button, add another user, click the submit
button again, and so on, BUT, disallow adding a user and then hitting
refresh (which would add the same user again) Any ideas on how to do
this??

Redirect immediately after inserting the record to the same page but
pass a parameter so you know to notify the user of a successful insert
eg header('Location: filename.php?message=success'); where filename.php
is the name of your script with the form on it. That way if you hit
refresh you're just getting the form and success message instead of
inserting the message agin.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

[Matt]

Excellent suggestion, but I have other preliminary PHP code (queries)
executing beforehand. Headers can only be modified if they are the
first thing within the script, otherwise errors are thrown. I ended up
fixing this problem in the same way in which you suggested, but using a
javascript redirect nested at the bottom of my php code. Thanks for
the help.

Matt Williams

[porneL]

On 17 Jan 2005 00:04:14 -0800, Matt <md*******@radford.edu> wrote:

Excellent suggestion, but I have other preliminary PHP code (queries)
executing beforehand. Headers can only be modified if they are the
first thing within the script, otherwise errors are thrown. I ended up
fixing this problem in the same way in which you suggested, but using a
javascript redirect nested at the bottom of my php code. Thanks for
the help.

Don't use JS redirects. Just enable output buffering (ob_start())
and you can set headers anytime.
Besides queries themselves don't output anything, so you could reorganize
code a bit to complete all actions before outputting anything.

Remember that you MUST set 303 response status when you redirect POST
request.
header('HTTP/1.1 303 Redirect');
--
* html {redirect-to: url(http://browsehappy.pl);}

[John Dunlop]

porneL wrote:

Remember that you MUST set 303 response status when you redirect POST
request.
header('HTTP/1.1 303 Redirect');

Although 303 is a more logical choice here, nothing stops
you from sending a 302 response. So make that 'MUST' a
'can', or a 'should' if interoperability with older software
isn't an issue, and I'll second that.

--
Jock

[porneL]

>> Remember that you MUST set 303 response status when you redirect POST

request.
header('HTTP/1.1 303 Redirect');

Although 303 is a more logical choice here, nothing stops
you from sending a 302 response. So make that 'MUST' a
'can', or a 'should' if interoperability with older software
isn't an issue, and I'll second that.

Right. It is actually SHOULD in RFC terminology.

But it is very important in this case, because current User-Agents
post form *again* on 301/302 status, so such redirect would *cause*
re-post instead of preventing re-post.

Only user-agent I know that doesn't understand 303 is Netscape 4.

Because 303 reponse may have a body and you can put link there,
you can have 100% compatibility (with extra "click here" for lousy UA).
--
* html {redirect-to: url(http://browsehappy.pl);}

[John Dunlop]

porneL wrote:

Remember that you MUST set 303 response status when you redirect POST
request.
header('HTTP/1.1 303 Redirect');

John Dunlop wrote:
Although 303 is a more logical choice here, nothing stops
you from sending a 302 response. So make that 'MUST' a
'can', or a 'should' if interoperability with older software
isn't an issue, and I'll second that.

porneL wrote:
Right. It is actually SHOULD in RFC terminology.
No, it's not; at least not in RFC2616. The RFC defines the
status code, but doesn't tell you when to use it.
But it is very important in this case, because current User-Agents
post form *again* on 301/302 status,
With a 301, that's what's supposed to happen. What browser
continues POSTing after a 302?
so such redirect would *cause* re-post instead of preventing re-post.
RFC2616 notes, sec. 10.3.3:

| RFC 1945 and RFC 2068 specify that the client is not
| allowed to change the method on the redirected request.
| However, most existing user agent implementations treat
| 302 as if it were a 303 response, performing a GET on the
| Location field-value regardless of the original request
| method. The status codes 303 and 307 have been added for
| servers that wish to make unambiguously clear which kind
| of reaction is expected of the client.

http://www.ietf.org/rfc/rfc2616.txt
Because 303 reponse may have a body and you can put link there,
you can have 100% compatibility (with extra "click here" for lousy UA).

Nothing stops you from providing a note along with a 302
response; in fact the RFC says you should (and that's a
'SHOULD'), unless the request method was HEAD.

I was never disagreeing with the sending of a 303, but I
thought your 'MUST' deserved a comment.

--
Jock

[Chris Hope]

porneL wrote:

On 17 Jan 2005 00:04:14 -0800, Matt <md*******@radford.edu> wrote:

Excellent suggestion, but I have other preliminary PHP code (queries)
executing beforehand. Headers can only be modified if they are the
first thing within the script, otherwise errors are thrown. I ended
up fixing this problem in the same way in which you suggested, but
using a
javascript redirect nested at the bottom of my php code. Thanks for
the help.

Don't use JS redirects. Just enable output buffering (ob_start())
and you can set headers anytime.
Besides queries themselves don't output anything, so you could
reorganize code a bit to complete all actions before outputting
anything.

Remember that you MUST set 303 response status when you redirect POST
request.
header('HTTP/1.1 303 Redirect');

The 303 redirect was really useful information and helped out with an
admin system I am putting together at the moment where I redirect them
after the form is posted, so thanks.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/