oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Apache Web Serving with Jaguar, Part 3

by Kevin Hemenway, coauthor of Mac OS X Hacks

Editor's note: In the first part of this series, Kevin showed you how to easily start serving web pages from your Mac OS X computer. In the second article, he explored the world of CGI access. Today, he looks at PHP and simple access controls.

Turning on PHP4

We're on the last legs of our trip down Feature Lane, Impressiville. This will be the easiest part of our journey because we'll be going through the paces based on what we already know. Much like CGI, PHP is very popular, well supported, and often installed on web hosts by default. Much like SSI, the code is included and interpreted into the actual HTML of your web pages.

Just like our other articles on CGI and SSI, turning on PHP involves searching for the feature name ("php") within our Apache configuration file. Note, however, that you may not have all the entries we're about to see--it depends on your operating system version, how upgrades took place, etc. If you don't have the lines below, just add manually. The first few entries we come to are

# LoadModule php4_module     libexec/httpd/
# AddModule mod_php4.c

These lines are just like those we encountered when we were messing with CGIs: they enable or disable the loading of PHP on a restart of our Apache web server. Since they're commented with that little # character, we've got to remove the # to enable them. Do that now.

Moving on to our next search result, we may or may not see:

# For example, the PHP 3.x module will typically use:
# AddType application/x-httpd-php3 .php3
# AddType application/x-httpd-php3-source .phps
# And for PHP 4.x, use:
# AddType application/x-httpd-php .php
# AddType application/x-httpd-php-source .phps

If we don't see these lines (which I didn't under OS 10.2.5), we'll need to add the last two ourselves (sans the # character). You can add them to the very bottom of your configuration file if you wish. Placement doesn't matter in this case. Double-check your spelling; if you mess up, either Apache won't start or PHP won't be configured properly. If these lines do exist, uncomment the last two.

These lines are similar to what we saw when we enabled SSI. In essence, they're saying that any file with the .php extension should be processed by the PHP module we just enabled (the Add and LoadModule entries). Save the Apache configuration file, and stop and start the web server using the "Sharing" preference panel.

We're going to return to our Apache error log for a second to illustrate a simple, yet helpful bit of information. Each time you start Apache, it will spit out a single line telling you that everything has started successfully. Often times, it will look like so:

[notice] Apache/1.3.27 (Darwin) configured -- resuming normal operations

When you add a third party module or feature (like PHP, mod_perl, mod_ssl, etc.), Apache will graciously make mention of it in its startup line. If you just restarted the web server, take a look at the error log by typing tail /var/log/httpd/error_log. You should see Apache wax poetic with something like:

[notice] Apache/1.3.27 (Darwin) PHP/4.1.2 
  configured -- resuming normal operations

Apache tells us that PHP is enabled, but how do we really know for sure? Rather easily, actually. Take that index.shtml file that we were testing SSIs with and rename it as index.php. Now, replace the contents with the following:

    <h1>Gleefully Served By Mac OS X</h1>
    <? phpinfo()?>

Finally, go to (not just'll see why in a later installment) and you should see a long page full of PHP diagnostic information. If so, rub your hands with a gleam in your eye, because PHP has now been added to your arsenal. Want to add a simple web-based email program for your traveling coworkers? Check out PHPost. (Note: Most PHP applications require a sophisticated database backend, like MySQL or PostgreSQL. PHPost is one of the few that doesn't. While installing and configuring these database systems is relatively easy on Mac OS X, we won't get into it until later in this series).

Mac OS X  in a Nutshell

Related Reading

Mac OS X in a Nutshell
A Desktop Quick Reference
By Jason McIntosh, Chuck Toporek, Chris Stone

Choosing Who Sees What

It's five in the morning. You've gone through three six packs of soda, two tins of Penguin Reds, and an untold number of delicious snacks and treats. You've got a CGI poll script ready to quiz the employees on the menu for the next company picnic, an SSI image gallery that happily sends the marketing department into a drool-dripping feature panic, and a PHP app with which your developers can track and monitor their sloppy code.

Now what?

After all you've done, something rather minor. We've just got to throw a little access control on our spunky new intranet. We wouldn't want the outside world seeing the insanely great job we've done (we'd rather wait and show them the really cool stuff we're gonna do on our personal time, right? Wink, wink, nudge, nudge).

While Apache can certainly handle authenticated access control, we're only going to touch on the location-based side of it for this article (stay tuned for password authentication). To do so, we're going to return to a snippet of configuration file that we've messed with before, when we were enabling SSIs:

<Directory "/Library/WebServer/Documents">
    Options Includes Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all

I mentioned we'd eventually touch on the remaining lines and now is the promised time (although, we're still going to rudely skip AllowOverride). Quite simply, the Order allow,deny and Allow from all entries are the magic that will stop outside visitors from perusing our intranet. Right now, as these lines stand, our intranet is wide open to the public.

This is what we're going to end up with:

<Directory "/Library/WebServer/Documents">
    Options Includes Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order deny,allow
    Deny from all
    Allow from

See what we've done here? The first thing we did is flip our Order directive. This tells Apache to process all Deny rules first and then the remaining Allow rules. Likewise, our first Deny is from all, meaning no one can come knocking. If we denied everyone, of course, no one would be able to see our work , so we add an Allow rule for our GatesMcFaddenCo domain. We can also allow and deny by IP, like Allow from 209.204.146. These changes will allow access to anyone from within the GatesMcFaddenCo network, but to no one from without.


Before you know it, it's seven in the morning and time to show off your efforts. You're confident, feigning a yawn of boredom, not sleepiness. As the morning sun glints off the silver of your glorious G4 tower, you smile privately. As has been typical since time began, doing something amazing on the Mac has been incredibly simple. Your boss is impressed, your coworkers are disbelieving, and you're signing a purchase order for the newest mystery item from MacWorld. Oh, life is good.

Don't think we've exhausted everything Apache and Mac OS X has to offer, though. You still haven't touched mod_ssl, which allows secure server capabilities, and you haven't fiddled with mod_perl, which can speed up your CGI scripts immensely. You haven't touched the authentication capabilities of Apache's access control or even tweaked Apache's configuration with .htaccess files. And sadly, if someone types in a bad URL for your intranet, you still get an ugly and generic 404 page.

Only 7:30? Plenty of time to bust those out before lunch. Good luck.

Kevin Hemenway is the coauthor of Mac OS X Hacks, author of Spidering Hacks, and the alter ego of the pervasively strange Morbus Iff, creator of, which bills itself as "content for the discontented."

Return to the Mac DevCenter.