PHP Form Submission Error

[spacemonkey]

I am hoping someone might be able to help to resolve an issue that has arisen recently with a number of websites I administer relating to contact form submission.

 

Host server version configuration:

Apache -

MySQL - 5.0.91-log

Perl - 5.8.8

PHP - 5.3.13

 

Until about a month ago all the contact forms were working correctly, but now whenever a user attempts to submit data via any of the contact forms the form produces the following error.

 

(The subject pulldown menu dictates the delivery destination of the form contact message):

Any data entered into any of the form fields ends up being duplicated - e.g.:

 

My SubjectMy Subject

 

instead of

 

My Subject

 

If I change the PHP code to accept My SubjectMy Subject instead of My Subject the form will submit but the data in the sent message is garbage - see below:

 

Message Subject: Mrs.Mrs.

 

Title: Mrs.Mrs.

First Name: SS

Last Name: OtherOther

Telephone No.: 0789012345607890123456

Mobile No.: 0789012345607890123456

Message: A message exampleA message example

Email: an.other@whatdoneit.coman.other@whatdoneit.com

[Jessica]

 

 

[requinix]

Host server version configuration:

Apache -

And there's the problem. Get your host to upgrade to version

[spacemonkey]

I am hoping someone might be able to help to resolve an issue that has arisen recently with a number of websites I administer relating to contact form submission.

 

Host server version configuration:

Apache - 2 (When I check the headers using Firebug I just get: Server Nginx / Varnish)

MySQL - 5.0.91-log

Perl - 5.8.8

PHP - 5.3.13

 

The named data is being retrieved via a process.php file as follows:

 

$subject .= $_POST['subject'];

$title .= $_POST['title'];

$forename .= $_POST['first_name'];

$surname .= $_POST['last_name'];

$phone .= $_POST['telephone'];

$mobile .= $_POST['mobile'];

$email .= $_POST['email'];

$message .= $_POST['message'];

$name .= $_POST['first_name'] . " " . $_POST['last_name'];

 

Until about a month ago all the contact forms were working correctly, but now whenever a user attempts to submit data via any of the contact forms the form produces the following error.

 

(The subject pulldown menu dictates the delivery destination of the form contact message):

Any data entered into any of the form fields ends up being duplicated - e.g.:

 

My SubjectMy Subject

 

instead of

 

My Subject

 

If I change the PHP code to accept My SubjectMy Subject instead of My Subject the form will submit but the data in the sent message is garbage - see below:

 

Message Subject: My SubjectMy Subject

 

Title: Mrs.Mrs.

First Name: SS

Last Name: OtherOther

Telephone No.: 0789012345607890123456

Mobile No.: 0789012345607890123456

Message: A message exampleA message example

Email: an.other@whatdoneit.coman.other@whatdoneit.com

 

I've tried researching the issue without any success so far. The following threads appear to indicate this is a bug:

 

http://stackoverflow.com/questions/13574369/php-post-variable-has-duplicate-munged-data

 

http://www.actionscript.org/forums/showthread.php3?t=210801

 

http://www.plantware.net/questions/13574369/php-post-variable-has-duplicate-munged-data

 

I've tried adding a dummy name/value pair by adding the following additional code into the contact form after the message field and before the re-captcha box:

 

<input type="hidden" name="splitter" value="1" />

 

but that did not work. (I may not have implemented that fix correctly, however.)

 

Any assistance would be greatly appreciated.

 

Thanks

[Pikachu2000]

Turn off register_globals in your php.ini file. Why a host would have that enabled by default in 5.3 is beyond me.

[requinix]

[edit] Ooh, nicely done Pikachu.

Edited January 6, 2013 by requinix

[Pikachu2000]

And even though your syntax to assign the values from the $_POST array to the variables is wrong, in this case it's what actually exposed the fact that register_globals is on. If you don't have access to your php.ini file, contact your host and request that it be turned off. If they won't, find a new host.

[Pikachu2000]

[edit] Ooh, nicely done Pikachu.

 

Why, thank you kind sir.

[spacemonkey]

Hi guys,

 

Thank you for your input, Pikachu2000. I've updated the PHP.ini file accordingly.

Hmm, thanks for the heads up about my poor coding. I've just checked the PHP online manual, but it does not appear to help me when I am trying to assign the posted data to a variable. Could you direct me to some other reference that better clarifies how I should be coding the $POST information?

 

Thanks again.

Edited January 6, 2013 by spacemonkey

[Jessica]

Use = instead of .=

Edited January 6, 2013 by Jessica

[Pikachu2000]

EDIT: The same thing Jessica said follows, but in a long-winded format : )

 

Using the .= (concatenation) operator appends a value to an already initialized variable. The = (assignment) operator initializes the variable and assigns a value to it. Since register_globals was silently initializing variables with names that correspond to the form field names without your knowledge, your .= operation was concatenating the same value to it again.

 

So to initialize and assign a value to a variable, use the = operator . . .

 

And if you're able to do so, restart Apache so the changes to php.ini take effect immediately.

[spacemonkey]

Thank you both, Jessica and Pikachu2000, for your help.

I will have to ask my provider when the server can be restarted.

 

Happy New Year to you all and many thanks again.

[spacemonkey]

Update:

 

The php.ini file has been updated and applied. The host provider has said the change would take effect immediately, but the issue persists. It may well be because the Apache server has not been restarted - understandable as this would affect other users.

I've run a pnpinfo() check to make sure that register_globals is now set to off.

Would anyone happen to know if there is a way to check when the Apache server was last restarted?

 

Thanks again for your patience.

[Pikachu2000]

If phpinfo shows it as off you should be good to go. What are the current symptoms and updated code?

[PFMaBiSmAd]

If you are on a shared web server, you would only have the ability to change a local php.ini, which would take effect immediately. It however would normally only apply to the folder where the local php.ini is at. Is the script you are having problems with in the same folder where your php.ini is at?

[spacemonkey]

The form now appears to be working properly, again. I think there must have been a short delay while the changes propagated to all the server cluster members.

 

Many thanks again for all your assistance and patience.