Apache Web-Serving with Mac OS X: Part 3

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 moves forward with a look at PHP.

Turning on PHP4

We're on the last legs of our trip down Feature Lane,
Impressiville. This will be the easiest section of our journey, mainly
because we'll be going through the paces based on what we already know.
Much like CGI, PHP is very popular and well supported, and very 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 sections on CGI and SSI, turning on PHP involves searching for the
feature name ("php") within our Apache configuration file. The first
entries we come up against are:

These lines are just like those we encountered when we were messing around
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.

We saw these same sorts of lines when we were enabling
SSI. In essence, they're saying that any file with the .php extension should
be processed by the PHP module we just enabled. As we'll see soon enough, Mac OS X (versions 10.1 and above) comes pre-installed with PHP 4, so go ahead and uncomment the two "for
PHP 4.x" lines. 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:

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 Apache Web server now, take a look at the error
log by typing:

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 to index.php. Now, replace the contents with the
following:

Finally, go to
http://127.0.0.1/index.php 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
Postgres -- PHPost is one of the few that doesn't. While installing and
configuring these database systems is relatively easy on Mac OS X, it would be
outside the scope of this primer. Want to see an article on this? Let us know by commenting below.

Choosing Who Sees What

This concludes our original vision for this series on Apache web serving with Mac OS X. In addition to your questions, what areas would you like us to explore next?

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 snacky
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. To do
so, we're going to return to a snippet of configuration file that we've
messed around with before, back when we were enabling SSIs:

I mentioned we'd eventually touch on the remaining lines, and now is said
time (although, we're still going to rudely skip AllowOverride). Quite
simply, the "Order allow, deny" and "Allow from all" lines 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.

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 all 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 Macstrosity (rather
phenomic, eh?), so we add an "Allow" rule for our GatesMcFaddenCo domain.
We can also allow and deny by IP, like "Allow from 209.204.146". This will allow
access to anyone from within the GatesMcFaddenCo network, but no one from
without.

Conclusion

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, nor have
you 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.