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.
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:
# LoadModule php4_module libexec/httpd/libphp4.so # AddModule mod_php4.c
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.
Moving on to our next search result, we 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
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:
[notice] Apache/1.3.20 (Darwin) configured -- resuming normal operations
When you add a third party module or feature
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:
You should see Apache wax poetic with:
[notice] Apache/1.3.20 (Darwin) PHP/4.0.6 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 to
index.php. Now, replace the contents with the
<html><body> <h1>Gleefully Served By Mac OS X</h1> <? phpinfo()?> </body></html>
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.
|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.
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:
<Directory "/Library/WebServer/Documents"> Options Includes Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all </Directory>
I mentioned we'd eventually touch on the remaining lines, and now is said
time (although, we're still going to rudely skip
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.
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 gatesmcfaddenco.org </Directory>
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.
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
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.
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 disobey.com, which bills itself as "content for the discontented."
Copyright © 2009 O'Reilly Media, Inc.