Preventing multiple form submissions

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

re: Preventing multiple form submissions

Matt wrote:
[color=blue]
> 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??[/color]

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/

re: Preventing multiple form submissions

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

re: Preventing multiple form submissions

On 17 Jan 2005 00:04:14 -0800, Matt <mdwilliam@radford.edu> wrote:
[color=blue]
> 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.[/color]

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);}

re: Preventing multiple form submissions

porneL wrote:
[color=blue]
> Remember that you MUST set 303 response status when you redirect POST
> request.
> header('HTTP/1.1 303 Redirect');[/color]

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

re: Preventing multiple form submissions

>> Remember that you MUST set 303 response status when you redirect POST[color=blue][color=green]
>> request.
>> header('HTTP/1.1 303 Redirect');[/color]
>
> 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.[/color]

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);}

re: Preventing multiple form submissions

porneL wrote:
[color=blue][color=green][color=darkred]
> > > Remember that you MUST set 303 response status when you redirect POST
> > > request.
> > > header('HTTP/1.1 303 Redirect');[/color][/color][/color]

John Dunlop wrote:
[color=blue][color=green]
> > 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.[/color][/color]

porneL wrote:
[color=blue]
> Right. It is actually SHOULD in RFC terminology.[/color]

No, it's not; at least not in RFC2616. The RFC defines the
status code, but doesn't tell you when to use it.
[color=blue]
> But it is very important in this case, because current User-Agents
> post form *again* on 301/302 status,[/color]

With a 301, that's what's supposed to happen. What browser
continues POSTing after a 302?
[color=blue]
> so such redirect would *cause* re-post instead of preventing re-post.[/color]

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
[color=blue]
> 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).[/color]

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

re: Preventing multiple form submissions

porneL wrote:
[color=blue]
> On 17 Jan 2005 00:04:14 -0800, Matt <mdwilliam@radford.edu> wrote:
>[color=green]
>> 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.[/color]
>
> 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');[/color]

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/