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.
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/libphp4.so
# AddModule mod_php4.cThese 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 .phpsIf 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 operationsApache 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:
<html><body>
<h1>Gleefully Served By Mac OS X</h1>
<? phpinfo()?>
</body></html>Finally, go to http://127.0.0.1/index.php (not just
http://127.0.0.1/--we'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).
|
Related Reading Mac OS X in a Nutshell |
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
</Directory>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 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 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 disobey.com, which bills itself as "content for the discontented."
Return to the Mac DevCenter.
Copyright © 2009 O'Reilly Media, Inc.