It's widely accepted by many that open-source software has many advantages over closed-source software. Whichever side of the fence you're on, one can't deny that it's an excellent way to learn the practical side of programming. In this article you'll learn how you can configure Apache to allow your visitors to learn from (or offer advice on) your source code through browsing it, in a manner similar to browsing ordinary Web pages.
Background And Usage
During the setup process of installing Apache on my home PC, I got the idea to make the source (that comprises a page) to be readily available via http requests to Apache. One could configure anonymous FTP access for downloading only on certain files and no access at all for others, or making copies of files to make available and placing them in special directories that have their files processed differently.
Instead of messing around with an FTP server or making lots of duplicate files, I opted for making a few small tweaks to Apache. With this method people can view server-side PHP code (and quite a few other server side languages) simply by making a small alteration to the current URL instead of having to fire up an FTP client, download the file and then open it in an editor. It allows a visitor to browse server-side code similar to the way they would look at client-side CSS and Javascript.
Unfortunately, it's not possible to show a working example on Webreference.com, but I can show you an emulated example. Imagine you have a page that allows visitors to type in a message that will be sent to you via e-mail when they hit the submit button. Its normal URL would be yourdomainname.com/contact/mail and would normally look like this. As usual, the visitor can view the HTML, but not the PHP. Accessing the same file via the source version URL (yourdomainname.com/source/contact/mail) would present a syntax-highlighted view of the original PHP code including comments and would look like this.
Implementation
It doesn't take much to make the work available to the public; all you need are a few simple tweaks to the Apache config and you're pretty much done. Also, thanks to the good folks at Zend (and probably numerous open-source contributors), PHP comes with a ready-made syntax highlighting feature. This generates PHP code with color-coding and indentation preserved without having to write your own syntax detection and highlighting script. It only works on PHP code, but it's still a nice touch.
The first thing to set up is your virtual directory for source viewing. I call my directory "source," but you can give yours any name you wish. (From now on we'll assume that you're calling it "source".) To do so, simply add an alias from the source viewing directory name to your Apache DocumentRoot. Whatever you do, do not make the alias point to your ServerRoot. The default location for the DocumentRoot on a Linux installation of Apache is /usr/local/apache2/htdocs (or /usr/local/apache/htdocs if you're not using Apache 2.x). If your hosting provider has performed the installation for you, it's likely they'll have changed it to something else. To check where your DocumentRoot is you can either ask your hosting provider's support contact or look for the DocumentRoot directive in your httpd.conf file. It will read something like this:
So just take what it says there and add it to an alias directive. So for a default setup,
will do the trick.
Once you've added your source viewing directory you need to give it its special attributes. Add a <Location></Location> section for your virtual source viewing directory and then pop the new directives inside it that will enable browsing of your source:
Options Indexes - when people request a directory and don't supply a file name they're allowed a listing of the contents of the directory. Next up is the DirectoryIndex none directive. With this directive a default index file is not served by default when a directory is requested without a file name. If an index file is forced on a browser when they request a directory, it's not going to be practical to browse around the directory structure. It's common for the DirectoryIndex to be something like "index.php" or "index.html" on a standard server, but this isn't standard stuff were doing here. The last two directives in the Location block are the ones that cause the change from files being processed in the usual way to being displayed as source.
tells the server to to present any file with the specified file extensions to be presented as PHP source code instead of being parsed and executed like normal PHP code. As you may have guessed,
directs the server to present files with the specified suffixes as plain text. If you're feeling adventurous, you can experiment with these directives and combine them with a few others to see what happens.
Sensitive Data Security
One other thing I strongly recommend is to shut off the more sensitive data on your domain from public viewing. Opening up your server so that people can learn from your code or leave feedback about how you can improve your code is of course a good thing; giving away passwords and other sensitive information is not. How you go about the process of keeping sensitive data private will depend largely on how the files on your system are (or perhaps are not) organized. My preferred (although perhaps not the most efficient) method is to have a configuration directory for programs I've written that to run on my host and to close it off from the public. I place all of my configuration code and passwords in this directory, then use them by way of inclusions. There's a good chance many of you will already have a similar system in place already. Anyone that's had to go through lots of files and read through countless lines of code to make the same small change over and over will know how much easier it is to change just one line of code in one file, than it is to have to change many lines in many files. For any other types of private files, you can put them in their own directory and use one common prefix in the directory name to signify their status. As an example, you could use private_
as a prefix for directories you want to keep private (eg. private_images
, private_testing
and so on). With your files organized in this way, you can protect all of them with just a few directives in a single block:
As usual, the directives make the assumption that your DocumentRoot is /usr/local/apache2/htdocs. The directives make the additional assumptions:
- The prefix you're using for private directory names is
private_
- You have a directory for config files for scripts/programs you write and run on your host (not the Apache server config) and the path to this directory is
/usr/local/apache2/htdocs/config. If you don't have such a directory and never will, then just replace the regular expression shown in the opening tag of the DirectoryMatch block with the following expression. "^/usr/local/apache2/htdocs/private_[^/]+/". ( Remove the "config|" bit and the surrounding brackets.)
- Ensure you have SSL/TLS available on the domain. If you don't have SSL/TLS available, you can remove the
SSLRequireSSL directive. Keep in mind, though, that no encryption means no protection when authenticating with your host or whilst browsing your private/configuration directories.
- Apache's DocumentRoot directory is the immediate parent of all directories with a
private_ prefix. So for example, /usr/local/apache2/htdocs/private_notes would require authentication before access, but /usr/local/apache2/htdocs/misc/private_notes would not require authentication. If you would rather be able to have a private_ prefixed directory anywhere then just replace the regular expression shown in the opening tag of the DirectoryMatch block with the following expression. "^/usr/local/apache2/htdocs/([^/]+/)*(config|private_[^/]+)/".
It's also important to note that a <DirectoryMatch> block is used rather than any other enclosure to ensure that these directives are applied to any http request for the directories and their contents regardless of the URL used in the request.
If you use one of those server administration GUI things, then make sure you add basic auth details for Apache. If you do things with a CLI then just use /usr/local/apache2/bin/htpasswd -c /usr/local/apache2/htpasswd/passwords yourname and provide the desired password when prompted. (Just make sure the directory /usr/local/apache/htpasswd exists first and that you replace "yourname" in the command with something more appropriate.) With that done, restart Apache and you should now have a Web host with source code that can be browsed by others so that they can hopefully learn from you, yet still requires authentication to view things you don't want open to the general public.
About The Author
Stephen Philbin is a freelance Web developer that likes to bring a little creativity to the practicality of the workings of the world wide Web. You can find Stephen in a constant state of frenzied tweaking at http://www.stephenphilbin.com.
This article originally appeared on WebReference.com.
IE 7
Firefox 2.0
