Clear POST variables on page refresh

I'm not sure if this is specifically a PHP problem, but here we go. Is =

there a way to clear the POST variables when the user refreshes a page? =
=

Specifically, my webpage POSTs a form to update or delete a record from =
=

the database -- it POSTs to itself, however. But if the user then clicks=
=

the browser's refresh button, it will try to delete or modify a =

non-existent record. I would like, if the users presses the refresh =

button, that PHP processes the page as no POST variables are set. I have=
a =

button on the page entitled "Reload" that executes a short Javascript: =

onclick=3Dwindow.location=3D which accomplishes the =
=

desired effect. But it tries to resend the POST information if the brows=
er =

refresh button is clicked.

I read something somewhere that seemed to imply this could be done with =
=

PHP sessions? Is this the way to go? If so, how?

Thanks for any help.

Richard Morley

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Clear POST variables on page refresh

Richard Morley
on Thursday, February 03, 2005 9:57 AM said:

> I'm not sure if this is specifically a PHP problem, but here we go. Is
> there a way to clear the POST variables when the user refreshes a
> page?

[snip]

> I read something somewhere that seemed to imply this could be done
> with PHP sessions? Is this the way to go? If so, how?

Don't know about the sessions bit but the regular way around this is to
POST your form to a processing page that redirects back to the form
page.

form.php -> processor.php -> form.php

When the users presses Refresh they will simply refresh the form page
and nothing else.



hth,
Chris.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Clear POST variables on page refresh

Richard Morley wrote:
> I'm not sure if this is specifically a PHP problem, but here we go. Is
> there a way to clear the POST variables when the user refreshes a page?
> Specifically, my webpage POSTs a form to update or delete a record from
> the database -- it POSTs to itself, however. But if the user then clicks
> the browser's refresh button, it will try to delete or modify a
> non-existent record. I would like, if the users presses the refresh
> button, that PHP processes the page as no POST variables are set. I have a
> button on the page entitled "Reload" that executes a short Javascript:
> onclick=window.location= which accomplishes the
> desired effect. But it tries to resend the POST information if the browser
> refresh button is clicked.

A simple thing to do is to put an md5 hash into the POST data, then only
do the insert if that md5 hash isn't already "used" when they hit refresh.

This avoids the hassle of re-direct headers and trying to follow
programming logic bouncing from script to script.

YMMV

--
Like Music?
http://l-i-e.com/artists.htm

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Clear POST variables on page refresh

Richard Lynch
on Thursday, February 03, 2005 11:26 AM said:

> A simple thing to do is to put an md5 hash into the POST data, then
> only do the insert if that md5 hash isn't already "used" when they
> hit refresh.=20
>=20
> This avoids the hassle of re-direct headers and trying to follow
> programming logic bouncing from script to script.

Come now, let's not be so dramatic. :P

"hassle of re-direct":


header("Location: http://fq.dn/page.ext");

?>

"programming logic bouncing from script to script":

It would be the same logic/handling of the form, just split across two
pages. Not really much changing is necessary. Except of course that you
will have to send data back to the form page via the querystring should
you have the need (i.e. form errors).


Not trying to knock you or the MD5 solution you offered. Just thought
you made the two page solution sound scarier than it really is.



Chris.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Clear POST variables on page refresh

> Richard Lynch
> on Thursday, February 03, 2005 11:26 AM said:
>
>> A simple thing to do is to put an md5 hash into the POST data, then
>> only do the insert if that md5 hash isn't already "used" when they
>> hit refresh.

Thank you for your responses. One question: If I were to use the md5 hash
method, what would be the best way to store used hashes? In a database? In
a temporary file kinda thing? Thanks again.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Clear POST variables on page refresh

Chris W. Parker wrote:
> Richard Lynch
> on Thursday, February 03, 2005 11:26 AM said:
>
>> A simple thing to do is to put an md5 hash into the POST data, then
>> only do the insert if that md5 hash isn't already "used" when they
>> hit refresh.
>>
>> This avoids the hassle of re-direct headers and trying to follow
>> programming logic bouncing from script to script.
>
> Come now, let's not be so dramatic. :P
>
> "hassle of re-direct":
>
> >
> header("Location: http://fq.dn/page.ext");
>
> ?>

Except if you start using sessions, but then need to not use cookies
because they're now "off" by default in browsers, so you use trans-sid,
will that PHPSESSID get tacked on to the end of the re-location header?

I think not.

So then you have a *TON* of code to fix, because somebody put all these
header("Location:") in the code and you need the PHPSESSID on the end of
every one of them.

> "programming logic bouncing from script to script":
>
> It would be the same logic/handling of the form, just split across two
> pages. Not really much changing is necessary. Except of course that you
> will have to send data back to the form page via the querystring should
> you have the need (i.e. form errors).

Months later, when trying to track down what is happening, you end up
opening up a file that matches the URL to find out what's going on, only
to find out it's not in that file because you did a header redirect to
another file, so then you open up that other file but then you find
another header redirect so then you open up another file, ...

You end up with 20 files open, with a snarled mess of header re-directs
bouncing you back and forth from file to file, for the very very very
common act of filling out a form.

No, thanks.

I'll stick to structuring my code so I don't need the re-direct.

> Not trying to knock you or the MD5 solution you offered. Just thought
> you made the two page solution sound scarier than it really is.

If it was only two pages, and there was only one header() re-direct, fine.

But what ends up happening is you get in the habit of doing this all over
the place, and you have a mess of spaghetti logic spread over a hundred
files.

At least, that's been my experience in trying to debug the mess people
have made with this header re-direct.

They can't use just one.

Perhaps you've had better luck with better programmers and header
re-direct usage -- All I know is, every time I find a header("Location:")
in somebody's PHP source code, I just know it's going to bite me in the
ass some day.

YMMV

Plus, the user can *STILL* use the pull-down menu of some browsers to go
back two pages and re-submit the form with the same data, or they can
click "back" fast enough to get there (on some browsers) and end up
re-loading the form that way.

If you need to be sure they don't do that, the md5 method will ALWAYS
work, not just "sometimes" work.

You want ALWAYS works or SOMETIMES works?

--
Like Music?
http://l-i-e.com/artists.htm

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Clear POST variables on page refresh

Ricky Morley wrote:
>> Richard Lynch
>> on Thursday, February 03, 2005 11:26 AM said:
>>
>>> A simple thing to do is to put an md5 hash into the POST data, then
>>> only do the insert if that md5 hash isn't already "used" when they
>>> hit refresh.
>
> Thank you for your responses. One question: If I were to use the md5 hash
> method, what would be the best way to store used hashes? In a database? In
> a temporary file kinda thing? Thanks again.

In a database with a datetime field.

Clear out anything older than a day or whatever in a cron job.

For a super busy site, you'd want to clear them out more often.

Or, to simplify matters, if you already have sessions, then do this:

session_start();

//Check their FORM freshness, and only process fresh input, not re-loaded:
$fresh = $_POST['fresh'];
$used = isset($_SESSION['used']) ? $_SESSION['used'] : array();
if (isset($used[$fresh])){
echo "Ignoring re-posted data: $fresh
\n";
}
else{
echo "INSERT INTO whatever (duplicate) VALUES ('$_POST[duplicate]')";
$used[$fresh] = TRUE;
$_SESSION['used'] = $used;
}

?>

Re: Clear POST variables on page refresh

You're wonderful. Thank you very much.



On Thu, 3 Feb 2005 13:02:14 -0800 (PST), Richard Lynch
wrote:

> Ricky Morley wrote:
>>> Richard Lynch
>>> on Thursday, February 03, 2005 11:26 AM said:
>>>
>>>> A simple thing to do is to put an md5 hash into the POST data, then
>>>> only do the insert if that md5 hash isn't already "used" when they
>>>> hit refresh.
>>
>> Thank you for your responses. One question: If I were to use the md5
>> hash
>> method, what would be the best way to store used hashes? In a database?
>> In
>> a temporary file kinda thing? Thanks again.
>
> In a database with a datetime field.
>
> Clear out anything older than a day or whatever in a cron job.
>
> For a super busy site, you'd want to clear them out more often.
>
> Or, to simplify matters, if you already have sessions, then do this:
>
> > session_start();
>
> //Check their FORM freshness, and only process fresh input, not
> re-loaded:
> $fresh = $_POST['fresh'];
> $used = isset($_SESSION['used']) ? $_SESSION['used'] : array();
> if (isset($used[$fresh])){
> echo "Ignoring re-posted data: $fresh
\n";
> }
> else{
> echo "INSERT INTO whatever (duplicate) VALUES ('$_POST[duplicate]')";
> $used[$fresh] = TRUE;
> $_SESSION['used'] = $used;
> }
>
> ?>
>

RE: Clear POST variables on page refresh

On 3 Feb 2005 Richard Lynch wrote:

> If it was only two pages, and there was only one header() re-direct, fine.
>
> But what ends up happening is you get in the habit of doing this all over
> the place, and you have a mess of spaghetti logic spread over a hundred
> files.

That is a problem with coding practices, not with the method used.

All you need to do is write a redirect() function used in all pages and
call it instead of header(). Then you have one point to change if you
need to make a change as you describe. The fact that someone did not
do this does not mean the underlying method is a poor idea. It just
means they didn't anticipate the need for application-specific code as
part of the redirect operation.

Put another way, it's a common error to fail to build an abstraction
layer for this type of low-level operation, but it doesn't mean using
the low-level operation is a mistake. The error, if there is one (and
I'd say there is in the scenario you describe) is in not noticing the
need for an abstraction layer.

--
Tom

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php