Tag: PHP

Plugging GD into PHP, on Leopard 10.5.7

Every Mac web developer will at some time in their lives have to deal with images. Unfortunately, the PHP installation on the Leopard OS (5.2.8 as of OS X 10.5.7) doesn’t have GD compiled in by default. If you’ve tried testing web components like CAPTCHA on your Mac, and can’t render the images, that’s the reason.

First and foremost, I try to make things easy around here. Before you begin the somewhat arduous task of compiling GD (and the pre-reqs) for your Leopard-powered Mac, there is a simpler solution: the Entropy PHP Apache module from Mark Liyanage. I used Mark’s work extensively when on Tiger, and both his compilations and instructions are what I consider the gold standard in simplicity and efficiency. Unless you have XCode tools handy and are really comfortable with the terminal window, I highly recommend going that route instead. When I compiled mcrypt for dynamic loading the Entropy package wasn’t available yet, but it is now and includes mcrypt too.

For those who don’t want an additional PHP install floating around on their machine and/or like everything updated when Apple says so, here’s how you get GD running with PHP on Leopard 10.5.7…


I like my cookies with encryption on top

Quick and dirty mcrypt usage

I don’t know where I discovered the original idea, but in messing around with a PHP app I found the need to encrypt session cookies. Here’s how it was done, with the mcrypt library:

//encrypt session cookie
function encryptUserCookie($value)
if(!$value) {
return false;
$text = $value;
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$crypttext = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $text, MCRYPT_MODE_ECB, $iv);
return trim(base64_encode($crypttext)); //encode for cookie

Decoding the cookie was much the same…

//decrypt session cookie
function decryptUserCookie($value)
if(!$value) {
return false;
$crypttext = base64_decode($value); //decode cookie
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$decrypttext = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, $crypttext, MCRYPT_MODE_ECB, $iv);
return trim($decrypttext);

SESSION_SALT was of course something I called from a variables file.

These snippets were used in an online directory system, where I didn’t want attendees inspecting the cookies for the purpose of setting up multiple listings under the same login.

Simple stuff, but hope it is useful to someone.

Plugging mcrypt into PHP, on Leopard 10.5.6

mcrypt on Fedora Core easy – on Leopard with PHP 5.2.6 not so much.

The instructions below cater to those folks who a) are developing on OS X Leopard 10.5.6, b) need the capabilities provided by mcrypt during their PHP development, and c) do not want to completely recompile PHP to get there. You’ll get mcrypt loading dynamically for use in PHP with this method.

First, you are going to need a few things…

1) libmcrypt-2.5.8, which you can pick up here;

2) PHP 5.2.6 source, which you grab here; and

3) Xcode 3 tools (dig through your sock drawer to find your Leopard disk).

Next, create a directory at root called ‘SourceCache’ and dump the files from #1 and #2 in there and unwrap.

Move to the libmcrypt-2.5.8 directory, and punch in this…

MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' LDFLAGS='-O3 -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' ./configure --disable-dependency-tracking

and then…

make -j6

and finally…

sudo make install

libmcrypt is ready – now for the PHP extension…

Move back to /SourceCache, then down to php-5.2.6/ext/mcrypt – type…

/usr/bin/phpize (phpize should be in /usr/bin – if not go find it and change the command as appropriate)

Then configure as follows…

MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' LDFLAGS='-O3 -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' ./configure --with-php-config=/Developer/SDKs/MacOSX10.5.sdk/usr/bin/php-config

Again make -j6 then sudo make install

Make sure you have php.ini in the /etc directory (it may be php.ini.default to start, so rename it). Ensure that enable_dl = On but do not remove the ; from in front of ;extension_dir = "./". UPDATE: Almost forgot – add one line to the .ini file in the Dynamic Extensions section… ‘extension=mcrypt.so’, without the quotes of course (thanks to Badrul).

Restart Apache – when all’s said and done you should be able to see this with phpinfo():

Special thanks go to salty beagle and Kenior Design for giving me the clues to getting the combination of events right.

MORE: Two commenters noted they had their success with the above after updated Xcode to 3.1.2.

Afterhours: Guinness Stout meets OpenSSL

My partner cranks through hundreds of RFCs, then directs me to tinker with the PHP libraries.

Thank you sir. May I have another?

I love trial and error assignments.

Have Fedora, but no mcrypt functionality for PHP?

Easy fix, despite the official line from PHP which says you need to recompile PHP –with-mcrypt.

I’ll caveat this by stating I’m using Fedora Core 7…

1) At the terminal, su root – you are now going to yum, not ./configure, make, and make install…

2) yum install mcrypt – this will get you libmcrypt, mhash, and mcrypt

3) yum install php-mcrypt – this will get you the functionality within PHP

Uh…done (without hassles).

“Pretty Hard to Protect”

PHP is under increased security scrutiny, which comes as little surprise.

PHP is a dynamic scripting language, and a favorite tool of hobbyists (think “personal home page”). Plenty of folks start open-source projects using PHP, those projects become popular for their ease of installation and use (think Mambo), and few pay attention to the cross-site scripting holes and the like until long after businesses decide to employ their use.

It’s not inherent flaws with the language per-se, but instead the effort PHP is going to have to make to get out of the “script kiddie” arsenal. Is this an opportunity for someone to set up shop doing nothing but fixing holes in PHP-based applications, or is the world going to wait for the open-source workhorses to find them themselves?

Burning a hole in my pocket, but I don’t care

My better judgement was tossed on the front steps this last Wednesday, the moment the MacMall sales associate told me there was no sales tax on products purchased online, for delivery to me.

New release Apple Powerbook G4 12 inch with Superdrive. 80gb hard, 512mb RAM, Airport Extreme, Bluetooth 2.0, etc. etc. Oops.

Now for some initial thoughts after tinkering around with it for the last six hours…….

Quick thanks on a PHP problem

I’ve got to pass thanks on to michaelk, Senior Member at Linux Questions.org for figuring out why my PHP scripts would not work on FC3, despite my crude attempt at explaining the problem.

Repeat after me…..PHP scripts must have Unix permission 644 in order to run on Apache. Again, PHP scripts must have Unix permission 644 in order to run on Apache.

Dumb mistake figured out by a quick thinker. Thanks again.