Subs Configuration Help

Note Before you configure Subs and as a separate exercise, you will have to set up the access control on your web site so that it uses the Subs password file to authorise users. Setting up the access control on your web server is not an optional step. If you do not do it, anyone and everyone will be able to access your supposedly protected information. Subs does not set up the .htaccess or .nsconfig files or whatever your web server needs to protect the files your users want to subscribe to. You will need to be (or have access to someone) familiar with the access control system on your web server in order to do this.

Index

• Configuration page
• Fields
• File Formats
• Lock File
• update
• convertDatabase
• Other configurable items
• pirateCheck
• Multiple configurations

You will usually have to enter the 'admin' user name and password before you can access the Configuration page.

To configure or reconfigure Subs, load that page, change some or all of the fields and press the "Change Configuration" button at the bottom of the page.

• DBM. Uses a Unix DBM, or NDBM file, depeding on what sort of DBM support is built in to your version of Perl. You should not choose this type if your Perl does not support DBM. DBM format will have superior performance to the other types, especially for large databases of more than 1000 users, however it is harder to process with standard Unix tools. If you specify DBM, Subs will create 2 files with .pag and .dir extensions.
• Flat File. This is a simple ASCII file format that is designed for good performance, and is easy to process with simple Perl scripts.
• Comma Separated. This is an ASCII file with comma separated fields and optional quotes. Its performance is not as good as DBM, and its a bit trickier to parse with Perl, but it is compatible with the import and export formats of many spreadsheet and other programs. See File Formats for details of the file format.

If you change the file name or file type after you have already populated your User Database, Subs will not copy or convert the file to the new location or format. You will effectively start a new database in the new location and format. The Subs distribution includes a utility to convert User Databases from one format to another. We recommend that you make a suitable choice of database type and location before you start to add users, and stick with them.

Password file name

The password file is an NCSA style password file, ie each line is of the form userName:encryptedPassword.

The password file will be rewritten whenever you edit a users details, whenever you press "Update Password File" or whenever the update program runs. It will contain an entry for every user with either Trial or Approved status, and whose access has started but not expired at that time.

Host computer type

• $input{'name'} is replaced with the users login name.
• $input{'password'} is replaced with the users password
• $input{'full_name'} is replaced with the users full name
• $input{'address1'} is replaced with the users address line 1
• $input{'address2'} is replaced with the users address line 2
• $input{'city'} is replaced with the users city
• $input{'state'} is replaced with the users state
• $input{'postcode'} is replaced with the users postal code
• $input{'country'} is replaced with the users country
• $input{'start_date'} is replaced with the actual start date of the subscription
• $input{'end_date'} is replaced with the actual end date of the subscription
• $config{'service'} is replaced with the service name that you entered in Your Service Name above.
• $config{'admin_name'} is replaced with the name you entered in Administrator full name above.
• $config{'admin_address'} is replaced with the name you entered in Administrator address above.

• No access until manual authentication
  New users are registered online with a status of "Wait for approval". They have no access rights until you process their payment request and set their access start and end dates. This option is best suited to sites that only have manual credit card processing.

  Normally you would regularly search for users with status "Wait for approval", and for each one found, you would process their payment request (the period they requested is shown at the bottom of the edit user page). You would then set a status of Approved Access Start Date of "today" and an "Access End Date" of, say "6 months" or whatever was requested. If a card could not be processed, you should set the account status to Held, which will deny access. You should also email the account holder informing them of the problem with their card.

• No access until manual authentication
  New users are registered online with a status of "Trial". They have full access rights, and will keep them until you process their payment request. Their Access Start and Access End Dates will be set according to the subscription period they requested. This option is best suited to sites that only have manual credit card processing, but who wish to be able to offer immediate access to new subscribers. There is an obvious risk in this policy, since unscrupulous people could subscribe with a bogus credit card, and get free access until you try to authenticate them.

  Normally you would regularly search for users with status "Trial", and for each one found, you would process their payment request (the period they requested is shown at the bottom of the edit user page). If the payment succeeds, set their account status to Approved. If a card could not be processed, you should set the account status to Held, which will deny access. You should also email the account holder informing them of the problem with their card, although there is every chance they will be uncontactable.

• Immediate access after authentication
  This is the safest and best Policy, but it requires that you subscribe to an online Credit Card processing agency such as CreditNet. With this policy, when a new users subscribes online, their payment request is automatically processed with the card processing agency you configured in Use this Card Processor. If their payment is authenticated, they are immediately set to Approved, and have immediate access to your web site.

• None
  This selects a credit card proccing software that will always reject the card. Do not choose this option if you select "Immediate access after authentication" in Online Registration Policy
• CreditNet
  This selects card processing by CCN. If you select this options you must configure the next 4 fields too. Please follow the instructions in Subs Installation in order to install and configure the CreditNet client software.

The password file is updated automatically whenever you add or edit a users details, whenever a user registers online or whenever you press the "Update Password File" button on an adminstrator page. But you should also arrange for update to run automatically at least once per day using the Unix cron(1) command. If you do this then users whose subscriptions expire will be automatically removed from the password file. If you didn't run update automatically from cron, you would have to press the "Update Password File" button manually at least once per day, otherwise your expired users would get extra days free access to your site.

Update is run automatically by pirateCheck, so you do not need to run update if you are running pirateCheck regularly.

If you do not understand how to set up cron jobs on your web server host, get your host administrator to help you.

A typical cron entry would look something like:
15 1 * * * cd /usr/local/etc/httpd/cgi-bin/subs/private; ./update
This will cause update to run at 1.15 am every day of the year. Update must be run from the directory where it is installed, hence the cd in the cron entry above.

PirateCheck works by looking through the web server access log file that you specify on the Subs Configuration page. It looks at all accesses to protected areas on your web server that occurred in the last 2 days, and counts the number of different browsers used by each user. If it detects more than 4 different browsers in use, it assumes that the user name is in circulation, marks it as Held, and sends email to the Subs administrator. Finally, pirateCheck rebuilds the password file. If you run pirateCheck regularly, you do not need to run update too.

If you do not understand how to set up cron jobs on your web server host, get your host administrator to help you.

A typical cron entry would look something like:
1 15 * * * cd /usr/local/etc/httpd/cgi-bin/subs/private; ./pirateCheck
This will cause pirateCheck to run at 1.15 am every day of the year. PirateCheck must be run from the directory where it is installed, hence the cd in the cron entry above.