To manage a members-only website, perhaps with a related publication, you need software that offers special kinds of functions. I'll detail these so you can evaluate members-only site management software on the basis of the features you feel you require.

1. Subscription

The first requirement of comprehensive members-only management software is to take paid subscriptions from prospective members. This is similar to many other e-commerce transactions, especially the sale of digital goods. The subscriber needs to be able to securely transmit a name, address, e-mail address, credit card information, username, and password while the e-mail address and password are rechecked to make sure they are correct.

The merchant needs to minimize credit card fraud, a particular problem with members-only sites. (See the companion article "Protecting a Members-Only Website from Credit Card Fraud.") If possible, you'll want to capture the subscriber's IP address, screen out free e-mail address domain names, and perhaps sign up with eFalcon for fraud detection.

2. Authentication

The second task is to prevent non-members from viewing your content so that they'll have to pay to read or see it. This means some kind of user authentication system, usually by means of a username and a password. While it's possible for a determined hacker to defeat almost any kind of security system, your job is to keep 99% of the non-paying public out of your site. You can't worry excessively about the 1% who get in without paying. I've seen several kinds of authentication systems, each of which has advantages and disadvantages:

1. Native Unix and NT access control and authorization systems. You've probably seen gray boxes that pop up when you go to protected URLs asking for a username and password in order to enter. Anything in the entire directory is protected by an .htaccess file that describes which users may and may not enter and the location of the password file to check in. It's fairly easy to protect a directory in this fashion, but managing the passwords for hundreds or thousands of users can be difficult without good software. Both CGI Script Center's Account Manager (http://cgi.elitehost.com/acctman/index2.html) and Verotel Billing Solutions (www.verotel.com) rely on a Perl program installed in your website's cgi-bin directory that manages an .htpasswd file so that only paid members have access to the protected directories. (For more information see an article in Apache Week: "Using User Authentication", www.apacheweek.com/features/userauth). Here's what the contents of a sample .htaccess file look like:

--------

Options Includes
AuthType Basic
AuthName "WilsonWeb.com Members-Only Area"
AuthUserFile /usr/local/etc/.../dir/.htpasswd
<LIMIT GET>
require valid-user
</LIMIT>

--------

Members-only programs usually provide a way so that users who forget their username and password can have them e-mailed to them, so long as their e-mail address matches the one they registered under. Unfortunately, the gray-box password query box doesn't provide a link to the account finder function.




It is possible, however, if you have appropriate permissions to the httpd.conf configuration file, to set the location of the default error files. Instead of the standard "Authorization Failure" screen, you can set:

ErrorDocument 401 /path/to/401_error.html

This way you can put an "account finder" query form on the "Authorization Failure" page which comes up if the user doesn't supply the right username and password.

2. Webpages served by a CGI program. Instead of displaying the webpages directly, a second layer is introduced so that a CGI program displays the protected pages only to those who have entered a username and password and have a temporary cookie on their web browser. An example is Authenticate.cgi found in the CGI/Perl Cookbook by Patchett and Wright (Wiley, 1997; ISBN 0471168963). I used this system for several years and it works quite effectively, though all the protected pages had to be in subdirectories of a single protected directory. Unfortunately, Authenticate.cgi doesn't integrate easily with the other functions needed in a members-only site subscription system.
3. ColdFusion authentication. ColdFusion, a database application program (along with similar database application programs) has a sophisticated system that enables you to show static ColdFusion pages (webpages with a .cfm extension and containing some database programming using CF tags) only to those who are logged into the system. Those who are not logged in see a message encouraging them to subscribe while those who are logged in see the content on the webpage. This is the system I am currently using for my Web Commerce Today articles and back issues. It requires users to accept a cookie. The site infrastructure is substantially more complex than a straight HTML site.
4. Dynamically generated webpages. Many larger sites these days generate webpages from content contained in a database. These webpages don't exist in real time, but only when requested by a web browser. Such webpages are referred to as dynamic as opposed to static. Of course, it's easy to use the same database to look up the user and restrict access to these pages to paid members only. In spite of the marketing disadvantages from lack of search engine access, a content management system is the only practical way to manage a huge site of thousands of webpages. PC Magazine reviewed content management systems in their March 20, 2001 issue (www.pcmag.com/category/0,2999,s%253D1619,00.asp). This URL is typical of dynamically generated webpages.

3. Maintenance and E-Mailing

A third task of members-only sites is maintenance. The more of this maintenance that can be performed by the subscriber, the less the administrator has to do. The most common problem is forgetting a username and password (or mistyping a case sensitive password). One way is for the user to give an e-mail address and if it matches a subscriber on file, have the username and password e-mailed to the subscriber.

But what if the subscriber has a new e-mail address? -- an extremely common occurrence. To save administrator time, why not identify the user online. The user could enter a first and last name. If they match uniquely, the user could be presented with a "challenge question" that the user answered during the subscription process, such as, "What is your mother's maiden name?" or "What is the first name of your first true love?" If the user answers correctly, then he or she would be admitted to the web interface to see or change the username and password or change an e-mail address.

I don't think that members-only sites will ever get entirely away from some human customer service by e-mail or telephone. But the more that can be automated, the easier such a site is to administer. Of course, automation can get expensive. Make sure that the income from your site will justify the cost of automating before investing lots of money for automation.

If part of the subscription is for a paid e-mail or print publication, then the administrator will need easy access to the subscriber database. Ideally, the online members-only software will be able to handle e-mailing a regular newsletter. Since my website is remotely hosted (as opposed to an in-house webserver), I download the updated file to my desktop to e-mail out the newsletters to subscribers using an e-mail merge mailing program (Gammadyne Mailer) and a DSL connection.

Monitoring is an important aspect of maintenance. To prevent people sharing their passwords with friends, some programs monitor how many IP addresses have been used to access the site for a particular username within a 24-hour period. The ability to disable abused passwords can protect the integrity of your system as well as help garner a few more subscriptions from converted freeloaders.

4. Renewal

The fourth task is to manage subscription renewal. Some systems automatically e-mail renewal notices to members a set number of days before expiration. Alternatively, you'll need to have access to the subscriber files so you can e-mail renewal notices. One decision you'll need to make when you begin a subscription publication is how to handle renewals. There are two main approaches:

• Opt out. Some periodicals are set up to renew automatically until cancelled, automatically billing the credit card periodically. For sites with a monthly subscription this may be more convenient for the subscriber, but for the most part it's the publisher that reaps the rewards of this approach. Inertia works in favor of the subscriber doing nothing and continuing a subscription.
• Opt in. More common for annual subscriptions is to require subscribers to indicate their desire to renew the subscription. This respects their freedom of choice, but publishers have inertia working against them. Many subscribers many never get around to renewing since it takes some effort. Renewal should be as easy as possible for the subscriber, preferably so they don't need to enter all their address information all over again. Some systems only require the subscriber to click on a link in an e-mail message to indicate their desire to renew.

5. Expiration

The fifth task is to expire subscribers who fail to renew their subscriptions. The best systems automatically check for records past the expiration date, and either automatically remove these individuals from the password file, or remind them of the need to renew if they attempt to access the system after expiration. It is possible to manually remove access permission, but this can be very time consuming if you have many expirations to deal with.

It is possible to run a members-only site manually, but the more your management software will do automatically, the happier your subscribers will be and the more time you'll save to invest elsewhere.