Tag Archives: FrontPage

security administration on a shared Apache web server

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:

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

migrating to WordPress – the easy way

As of December 5, 2012, the IdeaXchg home page became a WordPress-generated blog page.  Previously, the entire site was created and maintained through FrontPage, but this became increasingly cumbersome and outdated, since Microsoft stopped supporting FrontPage long ago.

I was not looking forward to the daunting prospect of converting lots of old pages into WordPress, but I did want to preserve much of this old content, at least for the time being.  So what I’ve done is simply to keep many old pages at their old URLs, while replacing the site’s old home page with the new WordPress-based home page.  This allows me to use WordPress, while simultaneously keeping most of the old site exactly as it was, for the benefit of search engines and visitors.

As a former user of FrontPage, it was not immediately obvious that this simple approach, intermixing WordPress and non-WordPress content, could be done so easily, because FrontPage is notoriously finicky about such games.  Any addition of content to a FrontPage web has to be done through FrontPage, or one risks disastrous consequences.  Barring any obvious naming conflicts, there is no such danger with WordPress.

Of course, I’ve only punted on the conversion of old pages into WordPress, but that’s OK with me – I’m no purist.  The site didn’t get any worse than it was before, and now I can convert what old pages I care to in my own sweet time.  Meanwhile, I’ve gained immediate access to the full power of WordPress.

It should be noted, however, that the WordPress Search Widget does not encompass any non-WordPress content.  I can live with that, since my FrontPage-based Search pages stopped working a while ago, and Google search within site is more than adequate.

related references:

converting site from FrontPage to WordPress

IdeaXchg started as a FrontPage-based web site on a shared Linux host, running Apache web server.  At long last, prompted by an Apache upgrade that no longer supports the FrontPage Server Extensions (FPSE) and years after Microsoft stopped supporting FrontPage, we’re migrating to WordPress version 3.4.2.  Our web hosting service supports WordPress at no extra charge, and they handled the WordPress installation, providing us with a new “wp.” subdomain in which to experiment with WordPress without disrupting the old FrontPage-based portion of our web site.

As an introduction to WordPress, I’ll begin by exploring its features and using them to make a series of postings about the experience of learning to use WordPress from scratch.