Handling Fee-Based Subscriptions for Your Podcasts - dummies

Handling Fee-Based Subscriptions for Your Podcasts

By Tee Morris, Chuck Tomasi

Getting your podcast listeners to donate a couple of bucks to you or buy your latest CD is one thing, but getting them to shell out money for the privilege of listening to your show is another matter altogether.

If you don’t have a preestablished following, a fee-based subscription approach likely won’t help you. If you do have a following but have never required anyone to give you money, you may find yourself with less of a following afterwards. Use this option sparingly — and only if you really think others are willing to give money to listen to your podcast. You’ll need to come to the decision whether you want x listeners for free, or 1/10 x listeners to pay — okay, that number is up, but it will definitely be far less than your current listener base.

One way to get your listeners interested in parting with their money would be to give them a sample of what to expect. Offer the first episode or two for free download and in them, mention how to get the rest. Another method is to offer the opening 15-20 minutes of your podcast for free, then offer the rest of the episode for a fee, provided your show has the content to follow it up with.

Securing your feed

Okay, we’re sure you’re wondering just how you prevent giving away your podcast to anyone who cares to download it, not just to those who pay for it. The answer is to create a secure RSS feed with logins and passwords.

It’s time to be blunt — setting up and maintaining a secure feed is a little ugly. You’re not exposed to all the technical warts and scars here. The process you see here simple but you still manage to get in touch with the inner code monkey that lurks in everyone.

To start, there’s nothing special about a secure feed. The web server handles prompting for the login and password. You are responsible for setting up the feed and a configuration file. If you’re using a web server based on Apache — which a lot of hosting providers are — the high-level technical bits look something like this:

  • Create a separate RSS feed for your protected content in a separate directory — let’s call it members.
  • In the new members directory, create a file called .htaccess with some special instructions. These instructions tell the web server where to look for accounts and groups allowed access to this directory.

The authentication process works like this:

  1. The Apache web server receives an instruction from the podcatching client to download the new feed file. It peeks inside the .htaccess file to find the logins and passwords.
  2. The podcatching client presents a prompt for a login and password.
  3. The user types his or her information.
  4. The podcatching client sends the info back to the web server. It checks to see whether a) the information provided is correct, and b) that the account is in a group with permissions to the directory.
  5. If both of those are correct, the feed is downloaded and processed by the podcatching client like any other feed.

A sample .htaccess file looks like this:

AuthType Basic

AuthName "Members Only"

AuthUserFile /www/users/chucktomasi/html/security/passwd

AuthGroupFile /www/users/chucktomasi/html/security/group

Require group members

The first line (AuthType) tells the server what type of authentication to use — for now, stick with what it says. The second line (AuthName) is the text that appears when the login/password prompt appears. The AuthUserFile line points to a file with login names and passwords. The AuthGroupFile file is a simple list of accounts associated with a group name. It’s important that the files indicated in AuthUserFile and AuthGroupFile are placed where the file says they are or this doesn’t work.

The contents of the .htaccess file are case-sensitive — except for the text between quotes. It’s extremely important you get the case right for this to work. One of your authors spent many hours trying to figure out why things didn’t work because he had Group instead of group.

A sample line from the AuthUserFile file looks like this:


In this example, the login name is chuck.tomasi, and the password is encrypted, so nobody can download your file and find out all the passwords. You, the podcaster, are responsible for creating and maintaining the AuthUserFile (and AuthGroupFile). For a small list of user accounts, it’s fairly easy to maintain the password file by hand, using a command-line utility called htpasswd — commonly provided as part of the Apache web server.

Not all hosting accounts provide access to a command-line interface. You should check with your web hosting provider to see whether you have this capability. If not, you may have to resort to creating and maintaining these files on another system and uploading the files. For Mac OS X users, you already have Apache installed and can access these tools from the Terminal window. Windows users have to download Apache to install them.

If you find yourself with a runaway hit podcast on your hands with lots of accounts, managing them can be a bit of a pain. In such a case, look at a product like aMember which is a PHP web interface that runs on your web server. Make sure your hosting account allows you to upload and run PHP programs beforehand, though.

A typical line from an AuthGroupFile file might look like this:


The format is pretty straightforward — first is the group name (members), then a colon (:), then a list of comma-separated names from the AuthUserFile file. You can name the group anything you like — as long as it corresponds to the Require group line in the .htaccess file. The AuthGroupFile can also manage multiple groups with each line following the same format described earlier.

The path less traveled

When you have your AuthUserFile and AuthGroupFile files set up, you must designate the physical path to them. You get the physical path to your password and group files from your hosting tech support.

Be sure to ask for the physical path and not the virtual path. A virtual path is a shortcut that the web server gets from the browser on the other end in a URL to get to your files — for example, /security/passwd. The physical is how the operating system on the web server gets to the same information — for example, /www/users/chucktomasi/html/security/passwd. Most modern podcatchers and RSS readers support basic authentication. If you would like more information on configuring an Apache file, refer to the Apache web page.

If all else fails, seek out an experienced web geek and offer pizza, extra cheese, and a six-pack of Red Bull!

A great example of a pay-for-podcasting is Bill O’Reilly. The former Fox News channel host has taken his cadre of loyal listeners and charges about $50 for a premium membership to his audio and video content (which includes a free gift.)