Renzo Clavijo wrote:
I know it's very simple but the question is: How can I erase the
values held in $_REQUEST such that when I press F5 or I click
"Reload" there are no messages sent again?
<?php
if(isset($_REQUEST['send_mail'])){
mail($_REQUEST['address_mail'],$_REQUEST['subject']
$_REQUEST['message']);
}
benmoreassynt wrote:
I would try something like this:
if(isset($_REQUEST['send_mail']))
{
mail($_REQUEST['address_mail'],$_REQUEST['subject']
$_REQUEST['message']);
unset($_REQUEST);
}
That should wipe all the variables in $_REQUEST before the user
clicks
reload. It will not work on a global variable if you use it inside a
function. There are other ways to do the same thing, but I think that
should do it.
No. That won't work. The variables will be sent to the server all over
again when the user reloads after sending the original email.
Quite right..
I use something as such
Somewhere in the <FORM> on your page enter a hidden field element such
as:
<INPUT TYPE="hidden" NAME="chksum" VALUE="<?=md5(mt_rand())?>">
Once submitted your form handling code [likely the same page] will
handle the _REQUEST or _POST or _GET [depending on what FORM METHOD you
specify in HTML]
Firstly run through your validation rules and if everything matches your
criteria and you are ready to proceed with the rest of the forward
progression [ie call to mail() in this case] then also do one more
check:
if($_SESSION["last_chksum"]!=$_POST["chksum"]) {
$_SESSION["last_chksum"]=$_POST["chksum"];
mail(....);
}
Easy??
All you do is validate that the passed POST chksum which was embedded
into form when sent to server DOESN'T match the one stored in the
session variable...
If so, then set the session variable to match that passed chksum and
continue with mailing or database updates or whatever procedure you need
to do..
When the user refreshes you see, the very same chksum will be sent back
from the browser at the time of when that form was processed originally
of course, therefore on the second iteration our conditional statement
will not evaluate to TRUE as the SESSION var now matches the chksum in
form.
Easy. And you can reprint the same page as well.
For example if they can enter more details in the form and press Ok
again [or whatever your submit button is for example] the form will now
contain a new random chksum and so it won't match the old stored one we
have set and it will send the mail out, but again, once it has sent the
mail once it also remembers the chksum associated.
Easy trick hey?
I see personally no problem with it and find its really the most
effective way.
Remember a few things though, this method relies on:
a) sessions [and therefore HTTP Cookies] must be accepted
b) do call session_start() before manipulating the superglob $_SESSION
c) there is a generous but limited life to session vars by default, but
you can use session set timeout directive to alter this behaviour, but
on the same note, analysing the issue we are trying to resolve here, it
is highly unlikely that someone would attempt to refresh and hence
resubmit a previously submitted page, say 48 hours after the first
submission. It just isn't a practical possibility, therefore we can
safely rest of the preexisting system default timeout [24 hours or one
week?? don't quote me]
Anyway thats that.. enjoy..
I guess the simplest solution is to do a redirect to a confirmation
page after sending the mail. That way a reload will not be reloading
the post but the confirmation page.
This won't prevent malicious spam. For that you will need to issue a
token and track submissions by token (and/or IP address).
(Also, please note:
--Your <form> tag lacks an 'action' property.
--You are not doing any validation of your input fields.
--By allowing the user to input the TO address, you are essentially
offering all the word an open relay for transmitting spam. This makes
you evil. May you soon be cut off by your ISP. Or repent and find
salvation :)
)
-J
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.1.392 / Virus Database: 268.5.1/327 - Release Date:
28/04/2006
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.392 / Virus Database: 268.5.1/327 - Release Date: 28/04/2006
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
