Running WordPress on a shared Linux web server is an economical way to build a web site without the hassle and expense of maintaining a dedicated server.  However, there are some useful administrative and security functions handled by the host’s Apache web server software configuration, beyond the scope of what is provided by WordPress.  While the main server configuration files generally are not accessible to users whose web sites reside on a shared server, Apache supports a powerful mechanism, .htaccess files, which can give individual users of shared web servers a high degree of control over the security and configuration of their own domains.

In my case, the immediate problem was to find a substitute for FrontPage’s directory-oriented password protection facilities.  In FrontPage, one would create a private “sub-web”, and the FrontPage Server Extensions (FPSE) provided an interface for registering users and assigning them passwords.  My problem was to continue supporting this simple model of access control (which uses the Basic Access Authentication protocol) without depending on FPSE.  This is not the sort of access control that is governed by WordPress’ blog-oriented administration features, but it’s an extremely simple application of Apache security features that can be implemented through .htaccess.

Because .htaccess files have many options and a rather obscure syntax, they can be quite confusing and intimidating.  There are many published tips and tricks on the use of .htaccess – so many that it can be hard to know where to begin.  Before you curse the complexity of .htaccess, though, remember that this mechanism spares you from the vastly greater complexity of managing your own web server, and it gives you a high degree of administrative control over your own web site running in a shared server environment.

An instructive illustration can be found in the solution to my problem of using .htaccess to replicate the access control features that were supported by FrontPage.  The only tool I needed to use was the WebShell file and directory management facility of the HSphere Control Panel, a standard feature offered by my shared web hosting service provider.  (An essential capability of WebShell that was missing from the free FTP program I’m accustomed to using is the ability to see .htaccess files at all – these and other files whose names begin with a period are not displayed in my old FTP utility!)

Using WebShell to peruse the residue of my semi-defunct FrontPage site, I could see that FrontPage’s implementation of password-protected sub-webs actually was based on the .htaccess mechanism.  The root of the password-protected sub-web contained a .htaccess file, and this referred to a standard type of encrypted password file, named service.pwd, residing in FrontPage’s hidden _vti_pvt subdirectory.  Even after the FrontPage Server Extensions ceased to operate, this access control mechanism continued to function properly.  But without the support of FPSE, it was unclear how to go about registering new users or making any other changes to my site’s password protection.

After wading though Apache documentation and various references, here’s what I came up with.  In the directory I wanted to protect I created a new .htaccess file containing this:

AuthType basic
AuthName "Montage subscriber area"
AuthUserFile [server path to password file]
Require valid-user


where [server path to password file] is the local path specification of my encrypted password file within the server filing system.  As for the password file itself, this is a text file containing entries of the following form:

joeblow:Fkazbh7cTThEY
anotherguy:dG6P5gnDxmj6M
user3:rvjN72pVDm4/w
user4:F11OoK8hj8QVo
user5:BhTY9V0rN7FKU
user6:WsmJQwNBm3rOs
etc.

I.e. each line begins with a username, followed by a colon, followed by the user’s encrypted password.  But where do the encrypted passwords come from?  There are a variety of ways to get these, including free online forms that can generate them for you.  Strangely, most of these free services also ask you to provide the associated userid, even though this should not be necessary, since the encryption depends only on the password, not the userid.  Another alternative is to create a simple PHP program, which can generate and display a valid encryption for a given password.  (Note that the encryption is really a hash, and its value is not unique.)

I was able to copy lines from my old FrontPage-generated password file, and these entries worked fine, even though I moved, renamed, and edited the password file.  For the problem of adding new users and passwords, I discovered that the HSphere Control Panel’s WebShell interface makes password file maintenance even easier, using its “Protect Wizard”.  This facility simplifies a number of basic .htaccess maintenance tasks, including the creation of encrypted password file entries in conjunction with adding, deleting, and modifying registered users.  Sheesh – if I had understood this in the first place, I’d never have had to learn as much as I did about the wonders of .htaccess!

Related references:

• http://httpd.apache.org/docs/current/howto/htaccess.html
• http://httpd.apache.org/docs/current/howto/auth.html
• http://httpd.apache.org/docs/current/howto/access.html
• http://httpd.apache.org/docs/2.4/configuring.html
• http://httpd.apache.org/docs/current/mod/directives.html
• http://www.dynamicnet.net/2011/05/htaccess-settings-for-wordpress/
• http://en.wikipedia.org/wiki/.htaccess
• http://en.wikipedia.org/wiki/Basic_access_authentication

Here is a sampling of additional references about .htaccess tips and tricks:

• http://www.catswhocode.com/blog/10-htaccess-snippets-to-optimize-your-website
• http://www.elated.com/articles/password-protecting-your-pages-with-htaccess/
• http://www.htaccesstools.com/articles/create-password-for-htpasswd-file-using-php/
• http://www.javascriptkit.com/howto/htaccess.shtml
• http://docs.joomla.org/Htaccess_examples_%28security%29
• http://perishablepress.com/stupid-htaccess-tricks/