It’s common for me to have clients that want an online version of their work in progress, but hidden from other eyes behind a username and password. While I recommend that you hold them responsible for providing hosting space in this situation, that’s not always possible. Also, there may be reasons for you to personally password-protect a directory on your server. This can easily be done through .htaccess.

.htaccess

In the directory you want to password protect, you should create (if they are not there already) two files: .htaccess and .htpasswd. In .htaccess, we will put the content telling the server where the username/password list (in .htpasswd) is, that a valid username/password is required to view the page they are trying to access, and what to show in the browser’s prompt:

# here is where we add the rules for requiring authentication
AuthType Basic
AuthName "SUPER RESTRICTED WEBPAGEALOOZA"
AuthUserFile /home/public_html/restricted/.htpasswd
require valid-user

So, in this example, I created a directory “restricted” on my jennschiffer.com server. /home/public_html/restricted/.htpasswd is the path to where the server will find the username/password combinations required to access that directory – so it will most likely be very different from your server’s path.

.htpasswd

Now we need to enter the username and password in our .htpasswd file. You want to encrypt your passwords, for obvious reasons. Lucky for us there are plenty of MD5 hashing tools out there to do the dirty work. I used htaccesstools.com’s htpasswd generator to do just that. My username is ‘pancake’ and my password is ‘syrup,’ so the generator says I should copy and paste the following into my .htpasswd file:

pancake:$apr1$lLamq...$hXRnB7f/KNynrY9D/Og7x/

Mmm, that’s some delicious looking syrup. If you want more than one username/password combination, put them on separate lines. That’s all you really need to password protect a directory–unless, of course, you just so happen to have WordPress installed in a directory above the one you’d like to protect.

Playing nice with WordPress

When I first did this for a client, I kept getting 404, or “page not found,” errors thrown at me. There was something in the .htaccess file, content generated by WordPress for controlling permalinks, that was screwing around with my own work. In order to prevent this, you need to go into the .htaccess file in the root of the WordPress installation and add the following before you see WordPress’ “#BEGIN WordPress” code:

ErrorDocument 401 /error.html
ErrorDocument 403 /error.html

401 and 403 errors are thrown when you are forbidden or unauthorized from viewing a page (like when someone gets the username/password combination incorrect). What we’re telling the server is to send users to a document in our root called “error.html” if the user is forbidden or unauthorized from viewing that directory, before WordPress tries to get involved. This should stop any false 404 errors. If you do not have an error.html document, change the line to reflect what page you do want the server to take the unauthorized jerk to – or make one.

Here is our prompt, where you should enter the username pancake and password waffle.

Haha I got ya, sucka. That’s not the right password, so you were sent to my error.html document.

Try it again, and put the right password (syrup).

Ah, much better.

So that’s it.

I hope this proves to be as useful to you as it is to me. It’s one thing to have a developmental server set up if you have a big client, or a local server if you are the only one seeing the work, but this is an easy and secure way to protect content on a live server…and to make sure WordPress doesn’t screw it up (for now).

4 notes • leave another