Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #4265 > unrolled thread

Trouble with sending e-mail from simple php script

Back to article view | Back to comp.lang.php

Contents

  Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-07 11:01 -0800
    Re: Trouble with sending e-mail from simple php script Luuk <Luuk@invalid.lan> - 2012-01-07 20:42 +0100
      Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-08 01:17 -0800
        Re: Trouble with sending e-mail from simple php script Luuk <Luuk@invalid.lan> - 2012-01-08 19:09 +0100
    Re: Trouble with sending e-mail from simple php script Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-07 16:06 -0500
      Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-08 01:20 -0800
        Re: Trouble with sending e-mail from simple php script Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-08 09:09 -0500
        Re: Trouble with sending e-mail from simple php script "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-08 15:12 +0100
          Re: Trouble with sending e-mail from simple php script The Natural Philosopher <tnp@invalid.invalid> - 2012-01-08 14:34 +0000
            Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-08 10:51 -0800
              Re: Trouble with sending e-mail from simple php script The Natural Philosopher <tnp@invalid.invalid> - 2012-01-08 22:02 +0000
                Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-09 05:27 -0800
                  Re: Trouble with sending e-mail from simple php script The Natural Philosopher <tnp@invalid.invalid> - 2012-01-09 14:35 +0000
          Re: Trouble with sending e-mail from simple php script Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-08 10:02 -0500
            Re: Trouble with sending e-mail from simple php script "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-08 16:33 +0100
              Re: Trouble with sending e-mail from simple php script Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-08 10:39 -0500
                Re: Trouble with sending e-mail from simple php script "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-08 17:01 +0100
                  Re: Trouble with sending e-mail from simple php script Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-08 15:44 -0500
                    Re: Trouble with sending e-mail from simple php script "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-08 23:53 +0100
                      Re: Trouble with sending e-mail from simple php script Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-08 19:00 -0500
                      Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-09 05:32 -0800
                        Re: Trouble with sending e-mail from simple php script The Natural Philosopher <tnp@invalid.invalid> - 2012-01-09 14:32 +0000
                        Re: Trouble with sending e-mail from simple php script Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-09 10:04 -0500
    Re: Trouble with sending e-mail from simple php script Jeff North <jnorthau@yahoo.com.au> - 2012-01-09 02:29 +1100
      Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-08 10:57 -0800
        Re: Trouble with sending e-mail from simple php script Jeff North <jnorthau@yahoo.com.au> - 2012-01-09 12:46 +1100
          Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-09 05:39 -0800
        Re: Trouble with sending e-mail from simple php script Captain Paralytic <paul_lautman@yahoo.com> - 2012-01-09 04:36 -0800
          Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-09 05:40 -0800
            Re: Trouble with sending e-mail from simple php script Captain Paralytic <paul_lautman@yahoo.com> - 2012-01-09 05:53 -0800
              Re: Trouble with sending e-mail from simple php script Tim Streater <timstreater@greenbee.net> - 2012-01-09 14:50 +0000
                Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-09 07:34 -0800
                Re: Trouble with sending e-mail from simple php script Captain Paralytic <paul_lautman@yahoo.com> - 2012-01-09 07:40 -0800
                  Re: Trouble with sending e-mail from simple php script Tim Streater <timstreater@greenbee.net> - 2012-01-09 17:00 +0000
                    Re: Trouble with sending e-mail from simple php script Captain Paralytic <paul_lautman@yahoo.com> - 2012-01-10 01:58 -0800
                      Re: Trouble with sending e-mail from simple php script Tim Streater <timstreater@greenbee.net> - 2012-01-10 10:18 +0000
                        Re: Trouble with sending e-mail from simple php script Captain Paralytic <paul_lautman@yahoo.com> - 2012-01-10 02:20 -0800
              Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-09 07:32 -0800
                Re: Trouble with sending e-mail from simple php script Tim Streater <timstreater@greenbee.net> - 2012-01-09 17:01 +0000
          Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-09 07:30 -0800
    Re: Trouble with sending e-mail from simple php script "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-08 17:19 +0100
      Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-08 11:02 -0800
        Re: Trouble with sending e-mail from simple php script "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-08 23:35 +0100
          Re: Trouble with sending e-mail from simple php script C <wrong.address.1@gmail.com> - 2012-01-09 05:28 -0800
            Re: Trouble with sending e-mail from simple php script The Natural Philosopher <tnp@invalid.invalid> - 2012-01-09 14:34 +0000
    Re: Trouble with sending e-mail from simple php script Luuk <Luuk@invalid.lan> - 2012-01-09 18:23 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#4353

On Jan 9, 12:53 am, "M. Strobel" <sorry_no_mail_h...@nowhere.dee>
wrote:
> Am 08.01.2012 21:44, schrieb Jerry Stuckle:
>
>
>
>
>
> > On 1/8/2012 11:01 AM, M. Strobel wrote:
> >> Am 08.01.2012 16:39, schrieb Jerry Stuckle:
> >>> On 1/8/2012 10:33 AM, M. Strobel wrote:
> >>>> Am 08.01.2012 16:02, schrieb Jerry Stuckle:
> >>>>> On 1/8/2012 9:12 AM, M. Strobel wrote:
> >>>>>> Am 08.01.2012 10:20, schrieb C:
>
> >>>>>>> Even if the message were rejected, I would still see
> >>>>>>> something
> >>>>>>> in that
> >>>>>>> frame, but I get only a blank frame. Client machine
> >>>>>>> rejecting the
> >>>>>>> message should not even be noticed by this PHP script, or
> >>>>>>> would it?
>
> >>>>>> You have to learn how to find and read the log files. Your
> >>>>>> script
> >>>>>> will not show errors if it dies.
>
> >>>>>> On Linux log files are only readable by root.
>
> >>>>>> /Str.
>
> >>>>> Log files are not always available, and PHP errors are often
> >>>>> not
> >>>>> written to logs (depending on the configuration - the
> >>>>> default is
> >>>>> to NOT write them).
>
> >>>>> Also, if the log files exist, they may easily be set up to be
> >>>>> read by others than root.
>
> >>>> Don't tell me, tell C.
>
> >>> No, you're the one who made the claims.  I'm just correcting your
> >>> misinformation.
>
> >>>> And the standard on linux is that log files are only root
> >>>> readable. I don't think it helps anybody if we start discussing
> >>>> what could all be done with the log files.
>
> >>> They can easily be changed - it has nothing to do with whether
> >>> you're using standard linux or not.
>
> >>>> Please do not start arguing with me on this level. I did
> >>>> Coherent
> >>>> on a serial terminal at home before linux came up, and I was
> >>>> working in an IBM computing center back then.
>
> >>>> /Str.
>
> >>> Great.  I was programming an IBM 1410 with punched cards in the
> >>> 60's and an IBM employee in the 70's - both long before Linux
> >>> came up.
>
> >>> When your statements are incorrect, I will correct them.
>
> >> I was glad the punched cards were gone when I came. The old
> >> operator could sort them by hand.
>
> >> There was nothing wrong with my statements. If he says "no log
> >> file" (which is not true, he said "blank frame") or "0 bytes in
> >> it" we know more, meanwhile it makes sense to suggest a standard
> >> setup.
>
> >> /Str.
>
> > No log file can be completely correct.  The default setup for PHP
> > does not include writing errors to a log file.
>
> Checked, and true, log_errors is 0.
> But display_errors is STDOUT.
>
> > Even if the
> > errors are written to a log file (very unusual in a shared
> > hosting environment), he will probably not have access to those
> > files.  The sysop can change the configuration (and some good
> > hosts do) to allow this, but it's uncommon.
>
> Is it? There would be no chance to find errors. Last 10 years I
> only have virtual and true servers.
>
> > You are the one who told him he needs to learn to find and read
> > the log files.  And you're the one who said they can only be read
> > by root. Neither statement is correct.
>
 > If he can delete php.ini he is on his own machine.

No, I am not.

(This work is done for a non-profit organisation voluntarily. A friend
got the server space and domain registration done. I tried to get a
basic www site established, so that I can hand over to others who
would then add information to it now and then.)

>
> > But it matters not because there is nearly a 0% chance he will be
> > able to read the log files.  So telling him to do it just sends
> > him off on a wild goose chase.
>
> I agree to the chance. It is hard to give a basic course in some
> newsgroups posts.
>
> > And as I told him - a blank frame is a different problem than
> > email not being received.  He needs to fix that first.

Getting a blank frame seems to be an additional problem. I have not
made progress on either problem yet.

>
> I told him, and it is incorrect, so I sent him into a loop ah
> goose chase, so he has no chance, and he listens to me instead of
> you, he needs to fix that first, that's my fault, because I don't
> care about security, ... Did I summon it up correctly?
>
> /Str.- Hide quoted text -
>
> - Show quoted text -

[toc] | [prev] | [next] | [standalone]

#4359

C wrote:
> On Jan 9, 12:53 am, "M. Strobel" <sorry_no_mail_h...@nowhere.dee>
> wrote:
>> Am 08.01.2012 21:44, schrieb Jerry Stuckle:
>>
>>
>>
>>
>>
>>> On 1/8/2012 11:01 AM, M. Strobel wrote:
>>>> Am 08.01.2012 16:39, schrieb Jerry Stuckle:
>>>>> On 1/8/2012 10:33 AM, M. Strobel wrote:
>>>>>> Am 08.01.2012 16:02, schrieb Jerry Stuckle:
>>>>>>> On 1/8/2012 9:12 AM, M. Strobel wrote:
>>>>>>>> Am 08.01.2012 10:20, schrieb C:
>>>>>>>>> Even if the message were rejected, I would still see
>>>>>>>>> something
>>>>>>>>> in that
>>>>>>>>> frame, but I get only a blank frame. Client machine
>>>>>>>>> rejecting the
>>>>>>>>> message should not even be noticed by this PHP script, or
>>>>>>>>> would it?
>>>>>>>> You have to learn how to find and read the log files. Your
>>>>>>>> script
>>>>>>>> will not show errors if it dies.
>>>>>>>> On Linux log files are only readable by root.
>>>>>>>> /Str.
>>>>>>> Log files are not always available, and PHP errors are often
>>>>>>> not
>>>>>>> written to logs (depending on the configuration - the
>>>>>>> default is
>>>>>>> to NOT write them).
>>>>>>> Also, if the log files exist, they may easily be set up to be
>>>>>>> read by others than root.
>>>>>> Don't tell me, tell C.
>>>>> No, you're the one who made the claims.  I'm just correcting your
>>>>> misinformation.
>>>>>> And the standard on linux is that log files are only root
>>>>>> readable. I don't think it helps anybody if we start discussing
>>>>>> what could all be done with the log files.
>>>>> They can easily be changed - it has nothing to do with whether
>>>>> you're using standard linux or not.
>>>>>> Please do not start arguing with me on this level. I did
>>>>>> Coherent
>>>>>> on a serial terminal at home before linux came up, and I was
>>>>>> working in an IBM computing center back then.
>>>>>> /Str.
>>>>> Great.  I was programming an IBM 1410 with punched cards in the
>>>>> 60's and an IBM employee in the 70's - both long before Linux
>>>>> came up.
>>>>> When your statements are incorrect, I will correct them.
>>>> I was glad the punched cards were gone when I came. The old
>>>> operator could sort them by hand.
>>>> There was nothing wrong with my statements. If he says "no log
>>>> file" (which is not true, he said "blank frame") or "0 bytes in
>>>> it" we know more, meanwhile it makes sense to suggest a standard
>>>> setup.
>>>> /Str.
>>> No log file can be completely correct.  The default setup for PHP
>>> does not include writing errors to a log file.
>> Checked, and true, log_errors is 0.
>> But display_errors is STDOUT.
>>
>>> Even if the
>>> errors are written to a log file (very unusual in a shared
>>> hosting environment), he will probably not have access to those
>>> files.  The sysop can change the configuration (and some good
>>> hosts do) to allow this, but it's uncommon.
>> Is it? There would be no chance to find errors. Last 10 years I
>> only have virtual and true servers.
>>
>>> You are the one who told him he needs to learn to find and read
>>> the log files.  And you're the one who said they can only be read
>>> by root. Neither statement is correct.
>  > If he can delete php.ini he is on his own machine.
> 
> No, I am not.
> 
> (This work is done for a non-profit organisation voluntarily. A friend
> got the server space and domain registration done. I tried to get a
> basic www site established, so that I can hand over to others who
> would then add information to it now and then.)
> 
>>> But it matters not because there is nearly a 0% chance he will be
>>> able to read the log files.  So telling him to do it just sends
>>> him off on a wild goose chase.
>> I agree to the chance. It is hard to give a basic course in some
>> newsgroups posts.
>>
>>> And as I told him - a blank frame is a different problem than
>>> email not being received.  He needs to fix that first.
> 
> Getting a blank frame seems to be an additional problem. I have not
> made progress on either problem yet.
> 
in my latest default debian squeeze mysql, the  default setup both rids 
me of magic quotes, which I had to re-enable, and also hides any errors 
from appearing on the users web browser..instead these are sometimes 
silently ignored, and sometimes appear the apaches error log.

The result is that a blank screen is not uncommon during any program bug 
- especially syntax errors.

I have not delved into this beyond that - since I have root access to 
the server keeping a screen monitoring apache errors is trivial.

Probably you need to get error reports to be directed to a useful file 
in your user space where you can pick over the remains...


I have never had occasion to do this, so I cant say how it might be done.

[toc] | [prev] | [next] | [standalone]

#4364

On 1/9/2012 8:32 AM, C wrote:
> On Jan 9, 12:53 am, "M. Strobel"<sorry_no_mail_h...@nowhere.dee>
> wrote:
>> Am 08.01.2012 21:44, schrieb Jerry Stuckle:
>>
>>
>>
>>
>>
>>> On 1/8/2012 11:01 AM, M. Strobel wrote:
>>>> Am 08.01.2012 16:39, schrieb Jerry Stuckle:
>>>>> On 1/8/2012 10:33 AM, M. Strobel wrote:
>>>>>> Am 08.01.2012 16:02, schrieb Jerry Stuckle:
>>>>>>> On 1/8/2012 9:12 AM, M. Strobel wrote:
>>>>>>>> Am 08.01.2012 10:20, schrieb C:
>>
>>>>>>>>> Even if the message were rejected, I would still see
>>>>>>>>> something
>>>>>>>>> in that
>>>>>>>>> frame, but I get only a blank frame. Client machine
>>>>>>>>> rejecting the
>>>>>>>>> message should not even be noticed by this PHP script, or
>>>>>>>>> would it?
>>
>>>>>>>> You have to learn how to find and read the log files. Your
>>>>>>>> script
>>>>>>>> will not show errors if it dies.
>>
>>>>>>>> On Linux log files are only readable by root.
>>
>>>>>>>> /Str.
>>
>>>>>>> Log files are not always available, and PHP errors are often
>>>>>>> not
>>>>>>> written to logs (depending on the configuration - the
>>>>>>> default is
>>>>>>> to NOT write them).
>>
>>>>>>> Also, if the log files exist, they may easily be set up to be
>>>>>>> read by others than root.
>>
>>>>>> Don't tell me, tell C.
>>
>>>>> No, you're the one who made the claims.  I'm just correcting your
>>>>> misinformation.
>>
>>>>>> And the standard on linux is that log files are only root
>>>>>> readable. I don't think it helps anybody if we start discussing
>>>>>> what could all be done with the log files.
>>
>>>>> They can easily be changed - it has nothing to do with whether
>>>>> you're using standard linux or not.
>>
>>>>>> Please do not start arguing with me on this level. I did
>>>>>> Coherent
>>>>>> on a serial terminal at home before linux came up, and I was
>>>>>> working in an IBM computing center back then.
>>
>>>>>> /Str.
>>
>>>>> Great.  I was programming an IBM 1410 with punched cards in the
>>>>> 60's and an IBM employee in the 70's - both long before Linux
>>>>> came up.
>>
>>>>> When your statements are incorrect, I will correct them.
>>
>>>> I was glad the punched cards were gone when I came. The old
>>>> operator could sort them by hand.
>>
>>>> There was nothing wrong with my statements. If he says "no log
>>>> file" (which is not true, he said "blank frame") or "0 bytes in
>>>> it" we know more, meanwhile it makes sense to suggest a standard
>>>> setup.
>>
>>>> /Str.
>>
>>> No log file can be completely correct.  The default setup for PHP
>>> does not include writing errors to a log file.
>>
>> Checked, and true, log_errors is 0.
>> But display_errors is STDOUT.
>>
>>> Even if the
>>> errors are written to a log file (very unusual in a shared
>>> hosting environment), he will probably not have access to those
>>> files.  The sysop can change the configuration (and some good
>>> hosts do) to allow this, but it's uncommon.
>>
>> Is it? There would be no chance to find errors. Last 10 years I
>> only have virtual and true servers.
>>
>>> You are the one who told him he needs to learn to find and read
>>> the log files.  And you're the one who said they can only be read
>>> by root. Neither statement is correct.
>>
>   >  If he can delete php.ini he is on his own machine.
>
> No, I am not.
>
> (This work is done for a non-profit organisation voluntarily. A friend
> got the server space and domain registration done. I tried to get a
> basic www site established, so that I can hand over to others who
> would then add information to it now and then.)
>

Non-profit or not, you need to set up a development machine which 
closely emulates what you have on the server.  That way you can write 
and test your code locally, while displaying error messages, etc.  Then 
once the code is working you can upload to the production server.

It's not that hard to set up a local machine.  There are packages out 
there which will help you, depending on your OS.

>>
>>> But it matters not because there is nearly a 0% chance he will be
>>> able to read the log files.  So telling him to do it just sends
>>> him off on a wild goose chase.
>>
>> I agree to the chance. It is hard to give a basic course in some
>> newsgroups posts.
>>
>>> And as I told him - a blank frame is a different problem than
>>> email not being received.  He needs to fix that first.
>
> Getting a blank frame seems to be an additional problem. I have not
> made progress on either problem yet.
>

That's why you need a local development server.

>>
>> I told him, and it is incorrect, so I sent him into a loop ah
>> goose chase, so he has no chance, and he listens to me instead of
>> you, he needs to fix that first, that's my fault, because I don't
>> care about security, ... Did I summon it up correctly?
>>
>> /Str.- Hide quoted text -
>>
>> - Show quoted text -
>



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#4295

On Sat, 7 Jan 2012 11:01:51 -0800 (PST), in comp.lang.php C
<wrong.address.1@gmail.com>
<19e29d83-3207-45e8-b63e-f476e7f900cc@u32g2000yqe.googlegroups.com>
wrote:

>| I have a simple form which is handled in a *.htm file by
>| 
>| <FORM METHOD="POST" ACTION="send_msg.php">
>| <PRE>
>|     Your name    <INPUT TYPE="text" NAME="name" MAXLENGTH=35 SIZE=50>
>|     Company  <INPUT TYPE="text" NAME="orgn"  MAXLENGTH=60 SIZE=50>
>|     City and country         <INPUT TYPE="text" NAME="locn"
>| MAXLENGTH=60 SIZE=50>
>|     Your e-mail address   <INPUT TYPE="text" NAME="emad"  MAXLENGTH=60
>| SIZE=50>
>|     Your message          <TEXTAREA NAME="question" WRAP=VIRTUAL
>| ROWS=5 COLS=45></TEXTAREA>
>|                           <INPUT TYPE="submit" VALUE="Send message">
>| </PRE>
>| </FORM>
>| 
>| Then the send_msg.php should send the e-mail by the following code
>| (but does not send e-mail). What am I doing wrong?

Apart from the other posters - you are not getting, validating nor
sanitising the input data.
 
>| <?php
>| $date = date("F jS Y, h:iA");
$name = $_POST['name'];
$orgn = $_POST['orgn'] etc etc
//-- now validate and sanitise the data

// then - if all is well, send out the email
>| if ($name == "" && $question == "") {exit;}
>| $host=@gethostbyaddr($REMOTE_ADDR);
>| $headers = "From: postmaster@domainname1.org \r\n";
>| $headers .= "X-Mailer: PHP \r\n";
>| if(mail("myusernamehere@gmail.com", "Comments from someone.",
>| "$host on the contacts page at $date \n
>| --- \n
>| $name from $orgn, $locn ($emad) wrote:\n\n
>| $question", $headers)) { $msg = "Thank you"; } else { $msg = "Message
>| not sent"; }
>| echo $msg;
>| ?>
>| 
>| <html>
>| <head>
>| 	<title>Test form to email</title>
>| </head>
>| 
>| <body>
>| <?php echo $msg ?>
>| 
>| 
>| </body>
>| </html>
>| 
>| <?php
>| echo "<HTML>";
>| echo '<BODY bgcolor="#E0FFE0" text="#008000" leftmargin="30"
>| topmargin="20">';
>| echo '<FONT face="Arial" size=1> <B>';
>| echo $msg ;
>| echo "Thank you. Your message has been sent.";
>| echo "</B> </FONT> </HTML>";
>| ?>
>| 
>| Thanks for all help/replies.
>| 
>| By the way, PHP.INI contained the following but suspecting this to be
>| a problem, I removed the file, and it still does not work.
>| 
>| register_globals = off
>| allow_url_fopen = off
>| 
>| expose_php = Off
>| max_input_time = 60
>| variables_order = "EGPCS"
>| extension_dir = ./
>| upload_tmp_dir = /tmp
>| precision = 12
>| SMTP = relay-hosting.secureserver.net
>| url_rewriter.tags =
>| "a=href,area=href,frame=src,input=src,form=,fieldset="
>| 
>| ; Only uncomment zend optimizer lines if your application requires
>| Zend Optimizer support
>| 
>| ;[Zend]
>| ;zend_optimizer.optimization_level=15
>| ;zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.3
>| ;zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/
>| Optimizer_TS-3.3.3
>| ;zend_extension=/usr/local/Zend/lib/Optimizer-3.3.3/
>| ZendExtensionManager.so
>| ;zend_extension_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.3/
>| ZendExtensionManager_TS.so
>| 
>| 
>| ; -- Be very careful to not to disable a function which might be
>| needed!
>| ; -- Uncomment the following lines to increase the security of your
>| PHP site.
>| 
>| ;disable_functions =
>| "highlight_file,ini_alter,ini_restore,openlog,passthru,
>| ;		      phpinfo, exec, system, dl, fsockopen, set_time_limit,
>| ;                     popen, proc_open,
>| proc_nice,shell_exec,show_source,symlink"

[toc] | [prev] | [next] | [standalone]

#4310

On Jan 8, 5:29 pm, Jeff North <jnort...@yahoo.com.au> wrote:
> On Sat, 7 Jan 2012 11:01:51 -0800 (PST), in comp.lang.php C
> <wrong.addres...@gmail.com>
> <19e29d83-3207-45e8-b63e-f476e7f90...@u32g2000yqe.googlegroups.com>
> wrote:
>
>
>
>
>
> >| I have a simple form which is handled in a *.htm file by
> >|
> >| <FORM METHOD="POST" ACTION="send_msg.php">
> >| <PRE>
> >|     Your name    <INPUT TYPE="text" NAME="name" MAXLENGTH=35 SIZE=50>
> >|     Company  <INPUT TYPE="text" NAME="orgn"  MAXLENGTH=60 SIZE=50>
> >|     City and country         <INPUT TYPE="text" NAME="locn"
> >| MAXLENGTH=60 SIZE=50>
> >|     Your e-mail address   <INPUT TYPE="text" NAME="emad"  MAXLENGTH=60
> >| SIZE=50>
> >|     Your message          <TEXTAREA NAME="question" WRAP=VIRTUAL
> >| ROWS=5 COLS=45></TEXTAREA>
> >|                           <INPUT TYPE="submit" VALUE="Send message">
> >| </PRE>
> >| </FORM>
> >|
> >| Then the send_msg.php should send the e-mail by the following code
> >| (but does not send e-mail). What am I doing wrong?
>
> Apart from the other posters - you are not getting, validating nor
> sanitising the input data.
>
> >| <?php
> >| $date = date("F jS Y, h:iA");
>
> $name = $_POST['name'];
> $orgn = $_POST['orgn'] etc etc
> //-- now validate and sanitise the data
>
> // then - if all is well, send out the email

I added four lines for those four variables.
What does this really do? I already have those values in the
variables. Why do we have to do this?

>
>
>
> >| if ($name == "" && $question == "") {exit;}
> >| $host=@gethostbyaddr($REMOTE_ADDR);
> >| $headers = "From: postmas...@domainname1.org \r\n";
> >| $headers .= "X-Mailer: PHP \r\n";
> >| if(mail("myusernameh...@gmail.com", "Comments from someone.",
> >| "$host on the contacts page at $date \n
> >| --- \n
> >| $name from $orgn, $locn ($emad) wrote:\n\n
> >| $question", $headers)) { $msg = "Thank you"; } else { $msg = "Message
> >| not sent"; }
> >| echo $msg;
> >| ?>
> >|
> >| <html>
> >| <head>
> >|   <title>Test form to email</title>
> >| </head>
> >|
> >| <body>
> >| <?php echo $msg ?>
> >|
> >|
> >| </body>
> >| </html>
> >|
> >| <?php
> >| echo "<HTML>";
> >| echo '<BODY bgcolor="#E0FFE0" text="#008000" leftmargin="30"
> >| topmargin="20">';
> >| echo '<FONT face="Arial" size=1> <B>';
> >| echo $msg ;
> >| echo "Thank you. Your message has been sent.";
> >| echo "</B> </FONT> </HTML>";
> >| ?>
> >|
> >| Thanks for all help/replies.
> >|
> >| By the way, PHP.INI contained the following but suspecting this to be
> >| a problem, I removed the file, and it still does not work.
> >|
> >| register_globals = off
> >| allow_url_fopen = off
> >|
> >| expose_php = Off
> >| max_input_time = 60
> >| variables_order = "EGPCS"
> >| extension_dir = ./
> >| upload_tmp_dir = /tmp
> >| precision = 12
> >| SMTP = relay-hosting.secureserver.net
> >| url_rewriter.tags =
> >| "a=href,area=href,frame=src,input=src,form=,fieldset="
> >|
> >| ; Only uncomment zend optimizer lines if your application requires
> >| Zend Optimizer support
> >|
> >| ;[Zend]
> >| ;zend_optimizer.optimization_level=15
> >| ;zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.3
> >| ;zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/
> >| Optimizer_TS-3.3.3
> >| ;zend_extension=/usr/local/Zend/lib/Optimizer-3.3.3/
> >| ZendExtensionManager.so
> >| ;zend_extension_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.3/
> >| ZendExtensionManager_TS.so
> >|
> >|
> >| ; -- Be very careful to not to disable a function which might be
> >| needed!
> >| ; -- Uncomment the following lines to increase the security of your
> >| PHP site.
> >|
> >| ;disable_functions =
> >| "highlight_file,ini_alter,ini_restore,openlog,passthru,
> >| ;               phpinfo, exec, system, dl, fsockopen, set_time_limit,
> >| ;                     popen, proc_open,
> >| proc_nice,shell_exec,show_source,symlink"- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

[toc] | [prev] | [next] | [standalone]

#4335

On Sun, 8 Jan 2012 10:57:23 -0800 (PST), in comp.lang.php C
<wrong.address.1@gmail.com>
<c18fd10b-1e24-4282-9dad-609366911cc3@o9g2000yqa.googlegroups.com>
wrote:

[snip]

>| > Apart from the other posters - you are not getting, validating nor
>| > sanitising the input data.
>| >
>| > >| <?php
>| > >| $date = date("F jS Y, h:iA");
>| >
>| > $name = $_POST['name'];
>| > $orgn = $_POST['orgn'] etc etc
>| > //-- now validate and sanitise the data
>| >
>| > // then - if all is well, send out the email
>| 
>| I added four lines for those four variables.
>| What does this really do? I already have those values in the
>| variables. Why do we have to do this?

If you are using just $name == '' then how is the value set from the
user's input? To do this you need to get the users input, place it
into your variables, validate and sanitise your data.

Your form uses the  method='POST' therefore the data will be sent to
the php file in the $_POST array.

[snip 2 end]

[toc] | [prev] | [next] | [standalone]

#4354

On Jan 9, 3:46 am, Jeff North <jnort...@yahoo.com.au> wrote:
> On Sun, 8 Jan 2012 10:57:23 -0800 (PST), in comp.lang.php C
> <wrong.addres...@gmail.com>
> <c18fd10b-1e24-4282-9dad-609366911...@o9g2000yqa.googlegroups.com>
> wrote:
>
> [snip]
>
> >| > Apart from the other posters - you are not getting, validating nor
> >| > sanitising the input data.
> >| >
> >| > >| <?php
> >| > >| $date = date("F jS Y, h:iA");
> >| >
> >| > $name = $_POST['name'];
> >| > $orgn = $_POST['orgn'] etc etc
> >| > //-- now validate and sanitise the data
> >| >
> >| > // then - if all is well, send out the email
> >|
> >| I added four lines for those four variables.
> >| What does this really do? I already have those values in the
> >| variables. Why do we have to do this?
>
-> If you are using just $name == '' then how is the value set from
the
-> user's input? To do this you need to get the users input, place it
-> into your variables, validate and sanitise your data.
->
-> Your form uses the  method='POST' therefore the data will be sent
to
-> the php file in the $_POST array.
>
> [snip 2 end]

It works on two other sites in that way. I did not even know about the
$_POST array until recently.

The contact page is in contact.php, and the action is send_msg.php.
This send_msg.php seems to know the values of Method=Post variables.

I have INPUT TYPE = "text" NAME = "name", etc. and send_msg.php should
know the values of $name, $locn, etc.

[toc] | [prev] | [next] | [standalone]

#4350

On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
> I added four lines for those four variables.
> What does this really do? I already have those values in the
> variables. Why do we have to do this?
>

You only have those values in variables if you are relying on
register_globals being on. The php manual has this to say on that
subject:

Warning
This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
feature is highly discouraged.

'nuff said?

[toc] | [prev] | [next] | [standalone]

#4355

On Jan 9, 2:36 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
>
> > I added four lines for those four variables.
> > What does this really do? I already have those values in the
> > variables. Why do we have to do this?
>
> You only have those values in variables if you are relying on
> register_globals being on. The php manual has this to say on that
> subject:
>
> Warning
> This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
> feature is highly discouraged.
>
> 'nuff said?

THIS MIGHT BE IT. I will try at home in the evening.

[toc] | [prev] | [next] | [standalone]

#4358

On Jan 9, 1:40 pm, C <wrong.addres...@gmail.com> wrote:
> On Jan 9, 2:36 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
>
> > > I added four lines for those four variables.
> > > What does this really do? I already have those values in the
> > > variables. Why do we have to do this?
>
> > You only have those values in variables if you are relying on
> > register_globals being on. The php manual has this to say on that
> > subject:
>
> > Warning
> > This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
> > feature is highly discouraged.
>
> > 'nuff said?
>
> THIS MIGHT BE IT. I will try at home in the evening.

There is no "might" about it. Jeff's suggested lines:

$name = $_POST['name'];
$orgn = $_POST['orgn'] etc etc

are the way it is done nowadays, because register_globals no longer is.

[toc] | [prev] | [next] | [standalone]

#4363

In article 
<36944289-58f2-4cc9-a12f-386aa9ad6da9@y7g2000vbe.googlegroups.com>,
 Captain Paralytic <paul_lautman@yahoo.com> wrote:

> On Jan 9, 1:40 pm, C <wrong.addres...@gmail.com> wrote:
> > On Jan 9, 2:36 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> >
> > > On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
> >
> > > > I added four lines for those four variables.
> > > > What does this really do? I already have those values in the
> > > > variables. Why do we have to do this?
> >
> > > You only have those values in variables if you are relying on
> > > register_globals being on. The php manual has this to say on that
> > > subject:
> >
> > > Warning
> > > This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
> > > feature is highly discouraged.
> >
> > > 'nuff said?
> >
> > THIS MIGHT BE IT. I will try at home in the evening.
> 
> There is no "might" about it. Jeff's suggested lines:
> 
> $name = $_POST['name'];
> $orgn = $_POST['orgn'] etc etc
> 
> are the way it is done nowadays, because register_globals no longer is.

Doing it this way provides some security. It means that the *only* way 
to get that data is via the $_POST array. So that means that your script 
doesn't start off with values in variables, assume they're OK, and use 
them. The old way meant someone could just run your script and preset 
*any* variable, even one you didn't mean to have set by the web page. So 
if you forgot to initialise $delete, but instead relied on it being null 
by default, and your code has this:

if  ($delete==1)
   {
   delete_complete_file_system ();
   }

the bad guy could easily do you some damage.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#4369

On Jan 9, 4:50 pm, Tim Streater <timstrea...@greenbee.net> wrote:
> In article
> <36944289-58f2-4cc9-a12f-386aa9ad6...@y7g2000vbe.googlegroups.com>,
>  Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
>
>
>
>
> > On Jan 9, 1:40 pm, C <wrong.addres...@gmail.com> wrote:
> > > On Jan 9, 2:36 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > > > On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
>
> > > > > I added four lines for those four variables.
> > > > > What does this really do? I already have those values in the
> > > > > variables. Why do we have to do this?
>
> > > > You only have those values in variables if you are relying on
> > > > register_globals being on. The php manual has this to say on that
> > > > subject:
>
> > > > Warning
> > > > This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
> > > > feature is highly discouraged.
>
> > > > 'nuff said?
>
> > > THIS MIGHT BE IT. I will try at home in the evening.
>
> > There is no "might" about it. Jeff's suggested lines:
>
> > $name = $_POST['name'];
> > $orgn = $_POST['orgn'] etc etc
>
> > are the way it is done nowadays, because register_globals no longer is.
>
> Doing it this way provides some security. It means that the *only* way
> to get that data is via the $_POST array. So that means that your script
> doesn't start off with values in variables, assume they're OK, and use
> them. The old way meant someone could just run your script and preset
> *any* variable, even one you didn't mean to have set by the web page. So
> if you forgot to initialise $delete, but instead relied on it being null
> by default, and your code has this:
>
> if  ($delete==1)
>    {
>    delete_complete_file_system ();
>    }
>
> the bad guy could easily do you some damage.
>
> --
> Tim
>
> "That excessive bail ought not to be required, nor excessive fines imposed,
> nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689- Hide quoted text -
>
> - Show quoted text -

Makes sense.

Thanks for the explanation.

[toc] | [prev] | [next] | [standalone]

#4370

On Jan 9, 2:50 pm, Tim Streater <timstrea...@greenbee.net> wrote:
> In article
> <36944289-58f2-4cc9-a12f-386aa9ad6...@y7g2000vbe.googlegroups.com>,
>  Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 9, 1:40 pm, C <wrong.addres...@gmail.com> wrote:
> > > On Jan 9, 2:36 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > > > On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
>
> > > > > I added four lines for those four variables.
> > > > > What does this really do? I already have those values in the
> > > > > variables. Why do we have to do this?
>
> > > > You only have those values in variables if you are relying on
> > > > register_globals being on. The php manual has this to say on that
> > > > subject:
>
> > > > Warning
> > > > This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
> > > > feature is highly discouraged.
>
> > > > 'nuff said?
>
> > > THIS MIGHT BE IT. I will try at home in the evening.
>
> > There is no "might" about it. Jeff's suggested lines:
>
> > $name = $_POST['name'];
> > $orgn = $_POST['orgn'] etc etc
>
> > are the way it is done nowadays, because register_globals no longer is.
>
> Doing it this way provides some security. It means that the *only* way
> to get that data is via the $_POST array. So that means that your script
> doesn't start off with values in variables, assume they're OK, and use
> them. The old way meant someone could just run your script and preset
> *any* variable, even one you didn't mean to have set by the web page. So
> if you forgot to initialise $delete, but instead relied on it being null
> by default, and your code has this:
>
> if  ($delete==1)
>    {
>    delete_complete_file_system ();
>    }
>
> the bad guy could easily do you some damage.
>
> --
> Tim
>
> "That excessive bail ought not to be required, nor excessive fines imposed,
> nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

I think I already knew that! And sorry but your post will now be
archived regardless of your setting.

[toc] | [prev] | [next] | [standalone]

#4372

In article 
<be2f03d3-5286-4919-a07a-0f2e93c73408@o14g2000vbo.googlegroups.com>,
 Captain Paralytic <paul_lautman@yahoo.com> wrote:

> On Jan 9, 2:50 pm, Tim Streater <timstrea...@greenbee.net> wrote:
> > In article
> > <36944289-58f2-4cc9-a12f-386aa9ad6...@y7g2000vbe.googlegroups.com>,
> >  Captain Paralytic <paul_laut...@yahoo.com> wrote:

> > > On Jan 9, 1:40 pm, C <wrong.addres...@gmail.com> wrote:
> > > > On Jan 9, 2:36 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> >
> > > > > On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
> >
> > > > > > I added four lines for those four variables.
> > > > > > What does this really do? I already have those values in the
> > > > > > variables. Why do we have to do this?
> >
> > > > > You only have those values in variables if you are relying on
> > > > > register_globals being on. The php manual has this to say on that
> > > > > subject:
> >
> > > > > Warning
> > > > > This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
> > > > > feature is highly discouraged.
> >
> > > > > 'nuff said?
> >
> > > > THIS MIGHT BE IT. I will try at home in the evening.
> >
> > > There is no "might" about it. Jeff's suggested lines:
> >
> > > $name = $_POST['name'];
> > > $orgn = $_POST['orgn'] etc etc
> >
> > > are the way it is done nowadays, because register_globals no longer is.
> >
> > Doing it this way provides some security. It means that the *only* way
> > to get that data is via the $_POST array. So that means that your script
> > doesn't start off with values in variables, assume they're OK, and use
> > them. The old way meant someone could just run your script and preset
> > *any* variable, even one you didn't mean to have set by the web page. So
> > if you forgot to initialise $delete, but instead relied on it being null
> > by default, and your code has this:
> >
> > if  ($delete==1)
> >    {
> >    delete_complete_file_system ();
> >    }
> >
> > the bad guy could easily do you some damage.

> I think I already knew that! And sorry but your post will now be
> archived regardless of your setting.

And for reasons best known to yourself, you introduced many blank lines 
near the top of your post and failed to snip my .sig.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#4387

On Jan 9, 5:00 pm, Tim Streater <timstrea...@greenbee.net> wrote:
> In article
> <be2f03d3-5286-4919-a07a-0f2e93c73...@o14g2000vbo.googlegroups.com>,
>  Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 9, 2:50 pm, Tim Streater <timstrea...@greenbee.net> wrote:
> > > In article
> > > <36944289-58f2-4cc9-a12f-386aa9ad6...@y7g2000vbe.googlegroups.com>,
> > >  Captain Paralytic <paul_laut...@yahoo.com> wrote:
> > > > On Jan 9, 1:40 pm, C <wrong.addres...@gmail.com> wrote:
> > > > > On Jan 9, 2:36 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > > > > > On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
>
> > > > > > > I added four lines for those four variables.
> > > > > > > What does this really do? I already have those values in the
> > > > > > > variables. Why do we have to do this?
>
> > > > > > You only have those values in variables if you are relying on
> > > > > > register_globals being on. The php manual has this to say on that
> > > > > > subject:
>
> > > > > > Warning
> > > > > > This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
> > > > > > feature is highly discouraged.
>
> > > > > > 'nuff said?
>
> > > > > THIS MIGHT BE IT. I will try at home in the evening.
>
> > > > There is no "might" about it. Jeff's suggested lines:
>
> > > > $name = $_POST['name'];
> > > > $orgn = $_POST['orgn'] etc etc
>
> > > > are the way it is done nowadays, because register_globals no longer is.
>
> > > Doing it this way provides some security. It means that the *only* way
> > > to get that data is via the $_POST array. So that means that your script
> > > doesn't start off with values in variables, assume they're OK, and use
> > > them. The old way meant someone could just run your script and preset
> > > *any* variable, even one you didn't mean to have set by the web page. So
> > > if you forgot to initialise $delete, but instead relied on it being null
> > > by default, and your code has this:
>
> > > if  ($delete==1)
> > >    {
> > >    delete_complete_file_system ();
> > >    }
>
> > > the bad guy could easily do you some damage.
> > I think I already knew that! And sorry but your post will now be
> > archived regardless of your setting.
>
> And for reasons best known to yourself, you introduced many blank lines
> near the top of your post and failed to snip my .sig.
>
> --
> Tim
>
> "That excessive bail ought not to be required, nor excessive fines imposed,
> nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

Snipping you sig would have prevented your complete message from
staying in the archive.

[toc] | [prev] | [next] | [standalone]

#4389

In article 
<2aca34ea-2565-446f-9b55-d14d7eeea0f2@p4g2000vbt.googlegroups.com>,
 Captain Paralytic <paul_lautman@yahoo.com> wrote:

> On Jan 9, 5:00 pm, Tim Streater <timstrea...@greenbee.net> wrote:
> > In article
> > <be2f03d3-5286-4919-a07a-0f2e93c73...@o14g2000vbo.googlegroups.com>,
> >  Captain Paralytic <paul_laut...@yahoo.com> wrote:

> > > I think I already knew that! And sorry but your post will now be
> > > archived regardless of your setting.
> >
> > And for reasons best known to yourself, you introduced many blank lines
> > near the top of your post and failed to snip my .sig.

> Snipping you sig would have prevented your complete message from
> staying in the archive.

And this is relevant just *how*, precisely, to anything at all?

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#4390

On Jan 10, 10:18 am, Tim Streater <timstrea...@greenbee.net> wrote:
> In article
> <2aca34ea-2565-446f-9b55-d14d7eeea...@p4g2000vbt.googlegroups.com>,
>  Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > On Jan 9, 5:00 pm, Tim Streater <timstrea...@greenbee.net> wrote:
> > > In article
> > > <be2f03d3-5286-4919-a07a-0f2e93c73...@o14g2000vbo.googlegroups.com>,
> > >  Captain Paralytic <paul_laut...@yahoo.com> wrote:
> > > > I think I already knew that! And sorry but your post will now be
> > > > archived regardless of your setting.
>
> > > And for reasons best known to yourself, you introduced many blank lines
> > > near the top of your post and failed to snip my .sig.
> > Snipping you sig would have prevented your complete message from
> > staying in the archive.
>
> And this is relevant just *how*, precisely, to anything at all?

Do you really need this explained?

[toc] | [prev] | [next] | [standalone]

#4367

On Jan 9, 3:53 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On Jan 9, 1:40 pm, C <wrong.addres...@gmail.com> wrote:
>
>
>
>
>
> > On Jan 9, 2:36 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > > On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
>
> > > > I added four lines for those four variables.
> > > > What does this really do? I already have those values in the
> > > > variables. Why do we have to do this?
>
> > > You only have those values in variables if you are relying on
> > > register_globals being on. The php manual has this to say on that
> > > subject:
>
> > > Warning
> > > This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
> > > feature is highly discouraged.
>
> > > 'nuff said?
>
> > THIS MIGHT BE IT. I will try at home in the evening.
>
> There is no "might" about it. Jeff's suggested lines:
>
-> $name = $_POST['name'];
-> $orgn = $_POST['orgn'] etc etc
->
-> are the way it is done nowadays, because register_globals no longer
is.- Hide quoted text -
->
> - Show quoted text -

You are right. This worked. I think I could also have set register
globals to on in PHP.INI.

[toc] | [prev] | [next] | [standalone]

#4373

In article 
<a89e1ca8-5d6a-401a-aa81-bba71d5bc00a@v13g2000yqc.googlegroups.com>,
 C <wrong.address.1@gmail.com> wrote:

> On Jan 9, 3:53 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> > On Jan 9, 1:40 pm, C <wrong.addres...@gmail.com> wrote:

> > > On Jan 9, 2:36 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> >
> > > > On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
> >
> > > > > I added four lines for those four variables.
> > > > > What does this really do? I already have those values in the
> > > > > variables. Why do we have to do this?
> >
> > > > You only have those values in variables if you are relying on
> > > > register_globals being on. The php manual has this to say on that
> > > > subject:
> >
> > > > Warning
> > > > This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
> > > > feature is highly discouraged.
> >
> > > > 'nuff said?
> >
> > > THIS MIGHT BE IT. I will try at home in the evening.
> >
> > There is no "might" about it. Jeff's suggested lines:
> >
> -> $name = $_POST['name'];
> -> $orgn = $_POST['orgn'] etc etc
> ->
> -> are the way it is done nowadays, because register_globals no longer
> is.- Hide quoted text -

> You are right. This worked. I think I could also have set register
> globals to on in PHP.INI.

Well you could have done but don't, OK?

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#4366

On Jan 9, 2:36 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On Jan 8, 6:57 pm, C <wrong.addres...@gmail.com> wrote:
>
> > I added four lines for those four variables.
> > What does this really do? I already have those values in the
> > variables. Why do we have to do this?
>
> You only have those values in variables if you are relying on
> register_globals being on. The php manual has this to say on that
> subject:
>
> Warning
> This feature has been DEPRECATED as of PHP 5.3.0. Relying on this
> feature is highly discouraged.
>
> 'nuff said?

THIS WAS IT.

register_globals is off by default and confirmed even by PHP.INI.
This meant that the variables $name, $locn were empty and the if
statements saw them as empty and decided that this was not a proper
message to be sent. Nothing happened after that (just exit) and
therefore also the blank frame.

Now it seems to be sending messages about 75% of the time. I tested
very many variations, and some of them are disappearing. This should
be in the logic in the code. If not, I will ask here with a new
subject line.

THANKS to all of you for trying to help and particularly to you, who
pointed out the essential thing.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web