Example of mail()

--0-1733122958-1146229429=:49607
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi all.

In the code bellow you'll find an easy to use example of mail().

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?

Thanks a lot for your help.


Best Regards


RENZO CLAVIJO

PD: Please forgive me if my english is not OK



--------------

Re: Example of mail()

Renzo Clavijo wrote:


> > if(isset($_REQUEST['send_mail'])){
> mail($_REQUEST['address_mail'],$_REQUEST['subject']
$_REQUEST['message']);
> }

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.

BMA

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

Re: Example of mail()

benmoreassynt wrote:


> I would try something like this:
>
>
> if(isset($_REQUEST['send_mail']))
> {
> mail($_REQUEST['address_mail'],$_REQUEST['subject']
> $_REQUEST['message']);
> unset($_REQUEST);
> }

As a follow up, if you want to use that in a public environment, you really
need to run the $_REQUEST array through something like strip_tags() at the
very least, and probably write your script in such a way that nobody can
inject headers into the form for spamming. The archives of the PHP mailing
list include ways to do it.

BMA

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

Re: Re: Example of mail()

> 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?
>> >> 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.

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

Re: Re: Example of mail()

>
>> 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?
>>> >>> 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 on your page enter a hidden field element such
as:



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 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