As a designer/front-end developer, I don’t have a lot of experience working directly with a web server in this manner, but as it’s the only way to password-protect a subdomain in my particular environment/situation (see below), I have no choice. After some searching online and some assistance from the ever-brilliant Michael Witwicki, I learned how to password-protect two subdomains on my web server and here is how I did it:

My Environment/Situation

• I needed to create and password-protect two subdomains—we’ll refer to them as test.bostonwebstudio.com and example.bostonwebstudio.com for the sake of this article
• I have a (dv) server from Media Temple with access to the secure shell (this isn’t provided by default, but can be obtained with a request to Media Temple’s support)
• I use a Mac, so I used Terminal to work in the secure shell. If you use Windows, I highly recommend using PuTTY

I’m willing to bet that the steps below will work in a variety of environments and situations but, again, I’m a bit weak in that area of knowledge so it’s up to you to determine if these steps will work for you.

Create the Subdomain(s) in Plesk

There isn’t much to write about, but this should be the first thing you do. If you need assistance with this and the Plesk Subdomain setup tool isn’t clear, read the official Plesk documentation on setting up subdomains.

It’s helpful to know that after a subdomain is created in Plesk on a Media Temple (dv) server, its location in the directory structure is: /var/www/vhosts/rootdomain.com/subdomains/subdomain. Again, this may be common in other server environments, or, it may not be.

Password-protect One of the Subdomains

As I wrote earlier, I needed to protect two unique subdomains with different credentials, meaning that the test.bostonwebstudio.com subdomain required a different username and password than the example.bostonwebstudio.com subdomain.

First, I’m going to explain how to set up the password-protection for one subdomain, then I’ll explain how to step through the instructions again with just a few details changed in order to create password-protection for a second subdomain.

1. Log into the server: Open your favorite command-line application and type: ssh username@domainname.com
   Replace username and domainname.com with your username and domain. You’ll be prompted for the password so enter it and press enter/return.
2. Move into the subdomain directory that you want to protect: Type: cd /var/www/vhosts/domainname.com/subdomains/subdomainname
   Replace domainname.com and subdomainname with your specific details and press enter/return.
3. Create the first necessary file (.htaccess): Type: vi .htaccess
   …and press enter/return. Doing this will both create a new file named .htaccess and open that file.
4. Add the necessary code to the .htaccess file:
   1. Press i to enter insert mode, which allows you to edit the .htaccess file, then copy and paste the code below into the window (or, type it exactly as it’s written):
      AuthUserFile /var/www/.htpasswd_test
AuthName “A Custom Message”
AuthType Basic
Require valid-user
      The value of AuthUserFile is the location where we’re going to put the second necessary file (.htpasswd_test) in step #6—I’ll explain why we’re using that particular location below
   2. Replace “A Custom Message” with anything you want and be sure to keep the double-quotes; it will be displayed to visitors in their log-in prompt.
   3. Save and close the .htaccess file by pressing the esc/escape key to exit insert mode, then type :wq (which stands for write and quit) and press enter/return. Doing this will save and close the .htaccess file, then bring you back to the command prompt.
5. Move into the directory that will contain the second necessary file (.htpasswd_test): Type: cd /var/www/
   …and press enter/return
6. Create the second necessary file (.htpasswd_test): Type: htpasswd -c .htpasswd_test username
   Replace username with the particular username you want visitors to use when they attempt to access your subdomain, then press enter/return. You will be asked to enter the password you want visitors to use; enter it and press enter/return. Finally, you will be asked to enter the password a second time, for security reasons, so enter it again and press enter/return.

In step #5 you moved into the directory /var/www/ and in step #6 you created a file in that directory which stores the username and password a visitor needs to enter in order to access the subdomain. There’s a good reason why we created the file in that particular directory; the /var/www/ directory is not accessible via the Internet or FTP, rendering anything you put in there fairly safe and hidden from prying eyes.

One Subdomain Complete, Now the Other

First, a summary and an explanation: by following the steps above you created a subdomain in Plesk, called test, and password-protected it using a command-line interface. If you were following along closely, you might have noticed that the second necessary file you created in step #6 was called .htpasswd_test. The ‘_test,’ tacked onto the end of ‘.htpasswd,’ represented the particular subdomain we were protecting: test.bostonwebstudio.com. If you were only ever protecting one subdomain, that file name could have remained ‘.htpasswd,’ but since we need two of these files, one for each subdomain, each file must have a unique name. My use of an underscore followed by the subdomain name is simply my personal preference; you may use any method/style you like, just be sure to use unique file names when protecting more than one subdomain.

Finally, in order to password-protect another subdomain, you simply repeat the steps above—starting with creating a subdomain in Plesk—while making sure that you move into the new subdirectory (step #2) and that you use a different filename for the second necessary file (referenced in step #4 and defined in step #6). If you were to follow the same conventions as above, the second subdomain’s .htpasswd file would instead be called ‘.htpasswd_example’

Disclaimer

Please remember, I am not a ‘web server pro’ by any means, I simply want to explain what worked for me in my particular environment/situation. I assume no responsibility if you wreak havoc on your web server by following these instructions; you do so at your own risk. In fact, I’d recommend that you consult your doctor before applying this information…

Additionally, I welcome any and all advice from anybody who can further improve these instructions.

A diagram of two different paths people often take when walking to and from a destination

An Observation: The Paths We Choose … Sounds deep doesn’t it? I’m not a very deep person, not unless I’m in the ocean and my buoyancy chose to stay on land. In fact, what I mean by The Paths We Choose is, quite literally, the paths we often choose when walking to and from a destination.

This rather pathetic diagram attempts to better describe what I mean: immediately after parking your car you set off on a particular path towards your destination, yet, on the way back to your car, you rarely follow the same path; in fact, you barely come close to it.

Granted, this is only the case when a straight line between the two points isn’t possible.

After taking note of this pattern in my own daily routines, I realized that this was something I do all of the time so I figured it was probably a common, yet unconscious, choice that many people made.

Maybe I should just stick to thinking and writing about HTML mark-up and CSS.

Too damned funny not to post.

We threw together a small website that, for the most part, relies on other websites to do most of the heavy lifting, we created a twitter account and wrote a few silly things in it, and we utilized Yahoo!’s Upcoming! website to handle the event and attendee details. Throw in a few instant messages to friends in the industry, a Facebook group (Thanks Paul!), a Flickr group for photos, and we were done with the online part. I then spent a very small amount of time visiting a few local restaurants to ask if they would have us for an evening and, finally, we spent about $30 on a geeky gift to give away.

That’s it. About 30 combined hours of work, $30 out of pocket, and we had created a simple social event for folks who do what we do. Once a few friends told a few of their friends we had our final and most important ingredient: people.

Since Angelo and I started the Build Guild I’ve had a few out-of-state friends say to me, “I wish we had something like that where I live.” I immediately think about how easy it was to start the Build Guild and I tell my friends that they should try to make a social event/group of their own; they might be surprised how many like-minded folks there are in their area. What’s the worst that can happen? Better yet, what’s the best that can happen?

My point here is that if you feel the same way—that there aren’t any web design & development social groups in your area—then try to start one. You might be surprised with what happens.