Building BobSmithPhotography.net has stopped expanding because I've been overwhelmed with spam on the comment forums. So, if you're here and have questions about web design come and visit Forums, Blogs, Wikis dot com. It has articles that I've written, some of which are also here, and a web design forum as well so you can ask any questions you may have. There is still a lot of good stuff here though, so poke around the links and take a look.

Home » Other Tips » Hosting Issues » Protecting directories

Protecting Directories

It is a fairly common practice for photographers to upload proofs to a private directory and then give the path to their client.  The thought is that since the path is never linked to it shouldn't ever be found.  While usually this is true, it is possible that your server is not set up correctly to be as secure as you'd hope.

Many photographers that proof with this method will create a folder off of their main site, let's call it /clients/, and upload each client to their own subfolder.  Aside from the subfolders there probably aren't any files in the /clients/ folder.  But what happens when a visitor browses to yoursite.com/clients/?  Have you checked?  Most servers are set up to return a 403 forbidden error, but many will show a page similar to the screen capture below.

Unprotected Directory You'll notice that you can see each of the client folders and a simple click will take you to their proofs.

So, what do you do?  How can we keep this page from being displayed?  There are two basic methods, although we'll go through several variants that go from very simple to fairly complex.  Any of the following will work to solve the problem.

index.html
The first, and probably easiest, method is to simply upload an index.html file to the /clicnts/ folder.  Most, if not all, servers are set up to display an index.html file as a default for a folder.  So a request for /clients/ will actually display /clients/index.html if it exists instead of showing the folder list. 

This file can contain anything you like.  If you look at many web applications they will include a small index.html file in each folder with a message along the lines of "Nothing to see here" for this reason. 

.htaccess
One step up the complexity level is an .htaccess file.  First, take note that the file starts with a period.  If you're used to Windows this may look odd, but it's fairly common on Linux / Unix systems.  It's a file with no name and an 8 character extension.

To protect using this method create an .htaccess file (it's just a simple text file) in the folder you're trying to protect with the following line.

Options -Indexes

If there is already an .htaccess file in the folder just add this line.  If there is already an Options line you can just tag -Indexes on to the end.  One caveat, if there is already a +Indexes after options just change the + to a -.

index.php
This trick comes from Robert Watcher on his forum over at ProPhotoForum.com. 

What we're going to do is build on the index.html method above, but make it automatically redirect to our home page instead of just showing a simple "Nothing to see here" message.  You will need to have PHP support on your server for this to work, although most hosts do have PHP installed.

Create a file called index.php in your folder and put the following code in it, changing www.yourdomain.com to your actual domain.

<?php
$redir = "http://www.yourdomain.com";
header("Location: $redir");
die();
?>

This will send a 302 redirect to the browser and they will jump from /clients/ to your root site. 

I'm sure something similar can be done with ASP, Cold Fusion, or any other scripting language; but it's been so long since I've done anything in ASP that I'm not sure exactly how.  If you can translate the PHP code to ASP, CFM, or .Net feel free to add it to the comments below and I'll add it - with credit of course.

.htaccess & Custom Errors
For the last method we're going to go back to the .htaccess file.  There is another directive we can use in the .htaccess file to tell our server what page to display in the case of a 403 error, which you'll recall is the error displayed when the Options -Indexes line exists in the .htaccess file.  Copy the following code to your .htaccess file, again changing yourdomain.com to your actual domain.  And don't worry about what it means, I'll explain underneath.

Options -Indexes
ErrorDocument 403 /

The Options -Indexes line we've already discussed.  The ErrorDocument line tells the server to show the file you specify in place of a generic error message whenever it would show a 403 forbidden error.  In this case we are telling the server to show your root page which is probably as good of a place as any to redirect them to.  Although you could just as easily redirect them to a page with a short message about why they were redirected.

One caveat for this method.  If you're using relative links to your images or other pages, this may break the links when your home page is displayed as an error page.  Let's say you're linking to your logo using <img src="logo.gif">.  Since the error page will be displayed under the /clients/ folder it will look for the image /clients/logo.gif which probably doesn't exist.  The easiest fix is to simply use a leading / in the src attribute, or the href attribute on links.   

Which to use?
So, which one should you use?  A very fair question.

If you're on a Windows server running IIS you cannot use either method that requires .htaccess, it's an Apache file.  However, if you're running on a Windows server with Apache instead of IIS (a very rare combination) it will work.  If you're on a Linux server, and you probably are, you can use any of the 4.

The index.html method is the easiest, with the index.php method only marginally more difficult.

The .htaccess methods have a major advantage however.  If, instead of putting the .htaccess file in the /clients/ folder, you put it in your web root it will protect every subfolder.  For example, if you have a /clients2004/, /clients2005/, and /clients2006/ folder placing an .htaccess file in your web root will protect all three. 

Personally, I'd go with the last method using .htaccess to redirect to back to the site root.

 
Content managed by the Etomite Content Management System.