Peter Mac And Associates

Using magic_quotes_gpc or addslashes()

I’ve worked on a bundle of web based applications over the years and time and time again I’ve seen the recurring problem of the slash. Yes, we’ve probably all seen it in one or more forums where the apostrophe some user entered, probably with the name O’Brein ends up as O\\Brein.

Why does this happen in sites running on PHP? The answer is a duplication of escapes. Yep, a Houdini Supreme.

Firstly a systems administrator has installed PHP and set the value for magic_quotes_gpc = on in the system’s php.ini (usually located in /etc/). This will automatically add slashes to all GET/POST/COOKIE data. This makes it safe before writing it to a database. Mr O’Brein becomes Mr O\\’Brein when magic_quotes_gpc is set to on.

Secondly, a programmer has come along and thinking they’re doing the right thing takes all user input and uses the addslashes() funtion to escape all quotes. This results in a doubling of the escapes so, Mr O’\\Brien now becomes MR O\\\\’Brein.

When this data is rendered, we see the automatic removal of only one set of escapes but the other set is left behind…yuck!!

When programmers see this they think…”I’ll just use the stripslashes() method, I mean, that’s what it’s there for”. As the light from the idea bulb fades, they realise they’re fixing a problem that should never have occurred in the first place. You need to go to the source of your data and clean it up, make sure you’re either using magic_quotes_gpc=on OR addslashes. My preference is to use addslashes all the time and turn magic_quotes_gpc off, this way the logic of your code explicitly sets user input to be what you want.

PHP mail function with postfix

I recently modified a web server to run Postfix instead of sendmail as it’s main MTA. The result was fairly pleasing and a Postfix/Imap/Webmail implementation meant my client was able to pick up and manage mail while travelling. One problem encountered however was the mail server was also a web server. Any time emails were sent using online forms, the resulting mail looked something like the following…

: No recipients specified
Reporting-MTA: dns; mail.threerock.com
X-Postfix-Queue-ID: 93E255C4E41
X-Postfix-Sender: rfc822; apache@threerock.com
Arrival-Date: Wed, 6 Sep 2006 08:26:14 +1000 (EST) Final-Recipient: rfc822; unknown
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; No recipients specified Received: by mail.threerock.com (Postfix, from userid 76)
id 93E255C4D4; Wed, 6 Sep 2006 08:26:14 +1000 (EST)
To: admin@threerock.com
Subject: Threerock Support - Report a Bug
From: “peter mac”

Reply-To: admin@threerock.com
Message-Id: 20060905222614.93E255C4D4@mail.threerock.com
Date: Wed, 6 Sep 2006 08:26:14 +1000 (EST)

After a bit of research and many different opinions from online groups, the fix turned out to be a simple change to the php.ini file (located in this case at /etc/php.ini)The change is as follows:look for the section [mail function] and create (if it doesn’t already exist) a key

sendmail_path = /usr/sbin/sendmail -t -i -f someone@yourdomain.com

Firstly check the path to your sendmail executable by typing

$ which sendmail

Secondly enter a valid username/domainname. This is the user the email will appear to come from. Examples are support@yourdomain.com, admin@yourdomain.com etc.

After saving your php.ini file, you will have to restart your httpd process.

$ /etc/rc.d/init.d/httpd restart