UserBase

Website Login System & User Manager

About

UserBase is a login system for your website that's simple to install (just 2 files) and requires very little configuration.  It runs on virtually any server because it is written in pure Perl and requires only MySQL support (or PostgreSQL, etc), both of which are available on the vast majority of webservers.

Live Demo

You can try out the UserBase Live Demo right now.

Screenshots

Here are a few screenshots of some of UserBase's admin-only pages:

• Administrator Main Menu
• Manage Users
• Add Fields to Signup Form

Features

• Simple installation
• Create unlimited user accounts and unlimited groups
• Can password-protect any PHP page or CGI script on your site (and any HTML file by changing its extension to php), as well as entire directories of files
• Supports optional paid accounts with simple PayPal-based configuration and multiple payment levels
• Users can sign up for their own accounts, including optional email verification and administrator approval
• User registration / signup page is customizable with unlimited form fields, to collect whatever user information is appropriate for your site
• Users can change their own passwords, and reset them via email if forgotten, without the need for the webmaster's intervention
• Login sessions can be restricted to user's current IP address for increased security
• Can automatically lock accounts after a number of failed logins
• Can automatically timeout an idle session after a period of inactivity
• Can be configured to prevent or allow multiple simultaneous logins by the same username
• Can sleep for a specified number of seconds on failed logins for protection against brute-force attacks
• Salts passwords and never stores any plaintext passwords; only stores salted encrypted versions
• Customizable landing page so when a user logs in, he immediately see links to the member-only and/or admin-only resources that you specify
• Optional automatic redirection to pages you specify after login/logout
• Works on virtually any server (known to work on Apache, IIS, Windows, Linux, and OS X Server) and any client (tested in Mozilla/Firefox, Opera, Internet Explorer, and Safari)

Download

UserBase is a Perl script, which means that it is a text file.  You can download the UserBase trial version (and its preferences file) and install it on your site right now; see instructions below.  The trial is designed for you to test on your server before purchasing the full version.  The trial version's limitations include the following:

• passwords cannot be changed or reset
• passwords are not encrypted
• usernames and passwords must be exactly 4 characters long
• there is no "remember me" (persistent login) option

Purchase

To get the full version of UserBase, please use the buttons below.

UserBase Full Version:
1-Website License	$39.99
3-Website License	$89.99
10-Website License	$249.99
Instant credit card payments through PayPal. No sign-up required!

Instructions

Download the script (see above) and rename it from userbase.txt to userbase.cgi.  You could also name it userbase.pl -- if you have a Windows/IIS server, you may need to.  Next, download the userbase_prefs.txt file and rename it to userbase_prefs.cgi.  DO NOT EDIT THE userbase.cgi SCRIPT unless absolutely necessary; instead, edit userbase_prefs.cgi for all your customizations.

Note: if you are using Microsoft Windows, and when you open the file, the lines all appear to be crunched together, try opening it in Wordpad (not Word) instead.  In Wordpad, save the file; this should fix the line-endings so the file's contents appear correctly in other editors like Notepad.

Note II: if you are running your server on Windows (in which case you'll need to install a copy of Perl, probably ActivePerl), then you'll need to change the first line of the script from #!/usr/bin/perl to either #!perl or #!c:\path\to\perl.exe

On your website:

1. Put the script at /cgi-bin/userbase.cgi.  (You could also name it userbase.pl, or in fact, whatever.cgi or whatever.pl.)  And put the prefs file at /cgi-bin/userbase_prefs.cgi.
2. Set the permissions on userbase.cgi (aka, chmod it) to world-readable and world-executable, that is, a+rx or mode 0755.  Do NOT use 0777.
3. Create the directory /cgi-bin/ubdata/ and set the permissions on it to world-readable, -writable, and -executable, that is, a+rwx or mode 0777.  On Windows servers you may also need to set a separate "Delete" bit. 
4. In your browser, go to yoursite.com/cgi-bin/userbase.cgi and follow the brief instructions that it gives you.  (It will instruct you to set the database options in userbase_prefs.cgi; these are $PREF{database_name}, $PREF{tmpfl1}, and $PREF{tmpfl2}.  Once these are set properly, UserBase will create a README file in your ubdata directory containing your initial login username and password.)
5. (Optional; recommended) If you'd like to use mysite.com/login/ instead of mysite.com/cgi-bin/userbase.cgi to access the script, then you can use one of these methods:
   
   SSI/shtml (most servers support this):
   Create /login/index.shtml and put this line in it:
   
   <!--#include virtual="/cgi-bin/userbase.cgi?$QUERY_STRING" -->
   
   If you're running Apache, you may also have to put these lines into your .htaccess file:
   
   

   DirectoryIndex index.shtml index.php index.html index.htm
   Options +Includes
   AddType text/html .shtml
   AddOutputFilter INCLUDES .shtml

   
   Then set $PREF{login_url} = "/login/"; in your userbase_prefs.cgi file.
   
   PHP:
   Create /login/index.php and then use one of these methods:
   
   Method A: copy and paste this line to the /login/index.php file:
   
   <?PHP virtual("/cgi-bin/userbase.cgi"); ?>
   
   Or:
   
   <?PHP virtual("/cgi-bin/userbase.cgi?" . $_SERVER['QUERY_STRING']); ?>
   
   Method B: save this file as call_userbase.php in your website's document-root (its top level), and then add this line to the /login/index.php file:
   
   <?PHP require($_SERVER['DOCUMENT_ROOT'] . "/call_userbase.php"); ?>
   
   Finally, set $PREF{login_url} = "/login/"; in your userbase_prefs.cgi file.
   
   Default content page (IIS only):
   If you're running IIS (on a Windows server) and the SSI and PHP methods above don't work, you can try setting userbase.cgi as a default content page.  Create the directory /login/ on your server and put your userbase.cgi into it.  Then open your IIS manager, find the /login/ directory, right-click on it and choose Properties.  Go to the Documents tab, check the "Enable default content page" box, and add "userbase.cgi" to the top of the list.
   
   Then set $PREF{login_url} = "/login/"; in your userbase_prefs.cgi file.
   
   META Refresh:
   Create /login/index.html and put this into it:
   
   

   <html><head><meta http-equiv="refresh"
    content="0;url=http://www.mysite.com/cgi-bin/userbase.cgi" />
   </head><body></body></html>
   

   
   
   Note that this just redirects your visitors from /login to /cgi-bin/userbase.cgi, so while it's better than nothing, the SSI or PHP methods above are better if your server supports them.
6. (Optional; recommended) For maximum security, consider purchasing and installing an SSL certificate on your server.  This allows you to use https:// URLs instead of http:// URLs, which encrypts all communications between your website and its visitors.
7. (Optional; recommended) Read the FAQ.

UserBase is now ready to use, and you can access it by visiting yoursite.com/cgi-bin/userbase.cgi (or yoursite.com/login/ if you created that).

 

Password-Protect Your Webpages

If your server supports PHP (most servers do) then you can use UserBase to password-protect web pages on it.  Here's how:

• Download the file userbase_check_login.txt onto your computer, then upload it onto your server in the top level of your webspace, and rename it to userbase_check_login.php.
• If the web page that you want to protect has some extension other than php, then change its extension to php.  For example if it's called mypage.html then rename it to mypage.php.
• In the following code, adjust $groups_allowed and/or $users_allowed to control access the way you want to, and then insert the code as the very first line in your PHP web page (it's split onto multiple lines here for readability; either single or multiple lines is fine):
  
  
  <?PHP
  $groups_allowed = "member,other_groupname";
  $users_allowed = "Joe,Steve,Bill";
  require($_SERVER['DOCUMENT_ROOT'] . "/userbase_check_login.php");
  ?>

Now when you visit that page in your browser, if you're not logged in, it will require you to log in first.

Password-Protect Whole Directories

For advanced, full-featured password protection of whole directories, you should use FileChucker in conjunction with UserBase.

But for basic password protection of whole directories, if your server supports PHP (most servers do) then you can do the following:

• Download the file userbase_check_login.txt onto your computer, then upload it onto your server in the top level of your webspace, and rename it to userbase_check_login.php.
• Download the file password-protect-folder.zip and unzip it; this will give you 2 files: .htaccess and index.php.  Edit the .htaccess file and replace "yoursite\.com" with your actual domain name (be sure to keep the slash), and then on the REQUEST_URI line, adjust the list of file extensions to protect.  Then just upload these 2 files into any directory on your website that you want to protect.

This basic whole-directory password protection has the caveat that it's based on the HTTP_REFERER variable sent by your visitors' browsers.  It's possible for malicious and relatively advanced users to spoof this variable, so you shouldn't use this method if the files that you're protecting are especially sensitive or confidential in nature.  And by this method, any link on your own website pointing to a file within the protected directory will bypass the protection; this is necessary so that the protected directory list itself can function, but it also means that you shouldn't create any other links to the files in the protected directory, unless you're OK with such links always working regardless of whether the user is logged in to UserBase.  Again, for more advanced whole-directory protection without these caveats, you should use FileChucker in conjunction with UserBase.

Password-Protect CGI Scripts

You can also use UserBase to password-protect other CGI scripts.  The code in the example script userbase_caller.txt shows you how.  Just copy and paste the code from it into your existing CGI script.

Support

If you are getting an Internal Server Error message when you try to access UserBase on your server, please try the solutions on our Internal Server Error page.

If you're getting errors about missing Perl modules, please see our instructions on how to install Perl modules.

If you still need help, you can contact us.

ChangeLog

v2.02 (20071106):

• The DBI database connection string is now an adjustable setting, so that users of non-MySQL databases such as PostgreSQL can change it without having to modify the actual CGI code.  (Prefs file updated; new pref is $PREF{dbi_connection_string}.)
• Improved error messages in a couple of places.
• Bugfix: using the subgroup-manager feature and the username-is-email-address feature at the same time did not work, because groupnames weren't allowed to contain "@", ".", etc.  Groupnames are now allowed to contain anything that usernames can contain.

v2.01 (20070925):

• When loading prefs, we now try userbase_prefs.cgi as a fallback, in case ${scriptname}_prefs.cgi does not exist, or in case the site has multiple instances of the script with different names, and wants a common set of base PREFs to apply to all of them.

v2.00 (20070923):

• The prefs filename is no longer hard-coded as userbase_prefs.cgi; instead it's ${scriptname}_prefs.cgi.  This is so that if you rename your userbase.cgi to something else like login.cgi, then you can (must) also rename your prefs file to login_prefs.cgi.
• New setting $PREF{forced_logout_link}, which templatizes some HTML that was previously hard-coded.  (Prefs file updated.)

v1.99 (20070829):

• If there are input validation errors during user sign-up or new account creation, we now display them at the top of the same page rather than on a separate otherwise-empty page, and we refill the old values so the user doesn't have to re-enter them, to make the whole process more user-friendly.  (Updates in the prefs file: $PREF{messages}{einvlde} and $PREF{css}.)
• The forcepwchng column is now a TINYINT(1) instead of a BOOL, with TRUE/FALSE values replaced with 1/0, to appease buggy versions of MySQL.  So users who previously could not use the $PREF{enable_forced_password_change} feature should now be able to.
• Improved error reporting in the email sub and a few other places.

v1.98 (20070823):

• New feature that allows you to specify a group of "sub-admins" (via $PREF{groups_limited_to_subgroup_user_mgmt} and $PREF{subgroup_groupname_suffix}).  Any user who's a member of this group is able to create accounts, but all created accounts will automatically be created as members of a group tied to this particular sub-admin; and the sub-admin is able to manage/delete accounts, but only those within his special group.  See the prefs file for full documenation.  Note that these PREFs and their documenation were actually added in the previous version, but the feature wasn't actually implemented until now.
• New feature $PREF{send_welcome_email_when_admin_creates_an_account}, with $PREF{welcome_email_subject} and $PREF{welcome_email_template}.  (Prefs file updated.)
• New settings $PREF{enable_forced_password_change} and $PREF{force_pw_chng_after_password_reset}.  These features existed before, but they were enabled by default and there were no PREFs for them, so there was no way to disable them.  They are now disabled by default because on some versions of MySQL they don't always work.  (Prefs file updated.)
• New settings $PREF{create_filechucker_userdir_on_account_creation}, $PREF{filechucker_userdir_folder} and $PREF{filechucker_userdir_folder_is_in_docroot}.  Obviously this requires FileChucker.  FileChucker creates userdirs automatically, but if you need them to be created immediately when an account is created, rather than when the new user visits FileChucker, this feature makes that happen.  (Prefs file updated.)
• Added the $PREF{protoprefix} setting to the prefs file, near the top of the prefs, so that it can be used within subsequent preference values.
• Renamed $PREF{userbase_data_dir} to $PREF{data_dir} for consistency with other Encodable apps.  (Prefs file updated.)
• PREFs file: in the documentation for the $PREF{print_full_html_tags} setting, in explaining the PHP virtual() function, we used a plus-sign to join two strings, but that should have been a dot instead, since in PHP the concatenation operator is the dot, not the plus-sign as it is in Javascript.

v1.97 (20070814):

• The external preferences file is now mandatory instead of optional, and UserBase comes with it already filled with all the prefs including their documentation.  This means that upgrades require a little more work, but first-time installations will be much easier, UserBase's configuration is easier to understand, and there are now few if any reasons to modify the actual application file, which greatly reduces the chances of various problems occuring during installation and configuration.
• New ?format=mini option and template for the login form, for situations where you want a small login form within the sidebar or header of an existing page.  This displays the user/pass fields if the user is not logged in, and displays a brief "$user logged in" message when the user is logged in.
• New setting $PREF{usernames_must_be_email_addresses}.  A few versions back we added the ability for usernames to be email addresses by allowing @-sign, dots, etc., in usernames; this new setting rounds out the feature by allowing site owners to REQUIRE that usernames be email addresses.  There's also a new setting $PREF{use_builtin_email_field} because you probably want to disable that field if you're using email addresses for the usernames.
• Moved some hard-coded text strings into adjustable preferences.
• Made user-signup and new account creation (by admins) easier by moving some of the basic input validation to the client side; for example making sure that the "password" and "password - verify" fields match, etc.  This saves a few trips to the server and makes the process quicker and easier.
• On the approve-or-delete-new-account page, we now display the values of any custom fields that exist on the site.
• New option $PREF{notify_admin_of_new_signups}, for situations where the admin doesn't want to have to approve new signups, but just wants to know when they occur.
• The auto-redirect preferences no longer need to be FQDNs.
• We now load prefs from a file named userbase_prefs_new.*, in addition to the default userbase_prefs.*, to facilitate upgrades.  The old prefs file can be kept in place and unchanged, while the new one can be renamed with _new, and both will be used.  In the long term you should migrate all your customizations to the new prefs file, but this works as an interim solution.
• Bugfix: if an error occurred before or during prefs-file processing, the error message that we displayed was raw and ugly, instead of within our HTML header and footer.
• Bugfix: if using $PREF{require_admin_approval_for_new_signups} without also using $PREF{require_email_verification_for_new_signups}, then approval and/or account creation would fail.

v1.96 (20070802):

• Our data directory is now specified as a relative path by default, which will simplify installation/configuration on some servers.
• Bugfix: the new quicker delete-user function introduced in the previous update failed to work if UserBase was installed/accessed via a short URL (i.e. mysite.com/login/ instead of mysite.com/cgi-bin/userbase.cgi).

v1.95 (20070802):

• Default values for administrative email addresses are now based on $ENV{HTTP_HOST} instead of being hard-coded to "@mysite.com".
• Removed requirement that usernames begin with a letter.
• Deleting a user account is now quicker and easier: it uses a Javascript prompt for the "Are you sure...?" message, rather than an entire dedicated page, saving a roundtrip to the server.  And upon deletion we just redirect back to the user list instead of displaying a "deletion successful" page.
• Added option for the send_email() subroutine to generate the email's message ID header field manually, for screwy servers/setups that fail to generate message IDs at the server-level.
• The redirection sub can now accept relative URLs, in which case we just automatically prepend the current protocol string and hostname.
• Bugfix: on some older versions of MySQL, the numusers database column always fails to be set; this caused the log_user_out_of_db() subroutine to fail.  We now do some extra checking to try and detect this condition to avoid displaying a confusing SQL error message.
• Bugfix: the force-password-change feature only worked when set by an admin on an account that already existed; it had no effect if used during the process of creating a new account.
• Bugfix: changed a -T to a -e while loading the prefs file, because some platforms don't do the -T test properly.

v1.94 (20070712):

• Improved instructions in the error message that's displayed when some of our required config files haven't been created.
• Changed the default names of some of our config files.

v1.93 (20070618) (internal):

• There is now a "delete" option for custom fields.
• Standardized the way we interpolate variables into templates.
• The chklogin feature, which allows calling UserBase from a PHP (or other) script to determine the user's login status, now returns all the custom field values as well as the previously-returned is_member, is_admin, username, etc.
• Changes to better support servers where DOCUMENT_ROOT is a UNC path.
• Bugfix: during email address verification, we tried to match on the creation date between the user table and the pending table, but those would never match, so if you had enabled email verification you would sometimes get an error about a null user ID.
• Bugfix: all template variables are now of the form %%var%% instead of %var% as before, because %foo% is ambiguous within a template that may also contain a URL with hex-encoded portions.

v1.92 (20070613) (internal):

• Yet more templatization.
• Restyled the login form so it looks a little nicer, is less wordy, and is slightly smaller.
• Bugfix: the add-custom-field logic now adds the custom fields to the pending table, in addition to the user table, and keeps both in sync.
• Bugfix: if you had set the email-verification and/or admin-approval options for new signups, and you also had some custom fields defined, upon signup we would always put the custom field values into the user table even when they should have gone into the pending table instead.

v1.91 (20070611) (internal):

• The "Manage Users" page now shows data from any custom fields you've added.
• The "Manage Users" page is now sortable by column, and there are now links to instantly show/hide columns.
• More templatization.
• The PREFs for specifying the admin-only and member-only links which appear on the main menu have been changed so that you can now specify different links for any group in your system, not just admin and member.
• Streamlined some of the code that displays error messages.
• Replaced a few instances of "UserBase" with the $PREF{webmaster_name} variable.
• The name of the "UserBase" link in the footer is now adjustable.
• Changed some of the CSS for the footer so it's more logical.

v1.90 (20070605) (internal):

• Site owners can now create unlimited custom form fields to be displayed on the user-signup form (and the admin add-new-user form) to collect whatever information from your users is necessary for your site.
• Option to disable the built-in "Real Name" field in case you want to create custom fields for first and last name separately.
• More templatization.
• Option to fall back to older hash functions on servers with outdated Perl and/or outdated Perl modules.

v1.89 (20070602) (internal):

• New options to allow dots, dashes, at-signs, and spaces in usernames.
• UserBase's CSS is now its own preference, so you can directly modify the styling without having to hack the code (previously, you could specify your own styling without hacking, but you couldn't change any existing CSS rules; you had to manually override them with your own).
• The login form is now completely templatized.
• Templatized a few small things like page titles, and standardized the display of error messages and success messages.

v1.88 (20070516) (internal):

• Bugfix: depending on whether you set the email-verification and/or admin-approval options for new signups, we sometimes errored out with an SQL problem.

v1.87 (20070509) (internal):

• Bugfix: on the Manage Users page, the "toggle extra info" link did not work in Internet Explorer.

v1.86 (20070425) (internal):

• Now the user-signup form can include a Terms of Use section with a checkbox that the user must check to agree to the terms.

v1.85 (20070413) (internal):

• Visitors can now sign up for their own accounts.  You can optionally enable mandatory email verification and/or mandatory administrator approval for all new sign-ups.
• Slight changes to the default styling.

v1.84 (20070406) (internal):

• New option to force a user to change his password, upon first login and/or upon password reset and/or whenever an admin decides it is necessary.
• The "Home" link in the footer is now customizable.
• New "Log Out All Locations" link for when prevent-multiple-simultaneous-logins is disabled and you want to log out any/all remote locations as well.
• Bugfix: on logout we failed to set the numusers column to zero, which meant that the footer would show "logged in from multiple locations" the next time you logged in, when it wasn't really true.  (Only affected users who had prevent-multiple-simultaneous-logins disabled.)
• Bugfix: if logging in with a nonexistent username, we sometimes returned an obscure SQL error instead of just saying "login failed."

v1.83 (20070330) (internal):

• Added new functionality that allows easily checking the login status programmatically by calling UserBase from a PHP script and parsing its output.  This means we now support the ability to password-protect any HTML file on virtually any server, by simply changing its extension from *.htm or *.html to *.php, and then adding a line of PHP to call UserBase and check the login status.

v1.82 (20070327) (internal):

• Bugfix: extremely old versions of MySQL (3.x series) would not allow UPDATEs on rows if the new value was the same as the old value, so we now work around it.
• Small steps towards internationalization and localization (i18n and l10n).

v1.81 (20070320) (internal):

• Changed the data type of the salt column for compatibility with older MySQLs.

v1.80 (20070301):

• Removed some old unused code.
• Improved the handling of auto-redirects upon login, whereby we automatically send the user back to the page he came from where he clicked the login link.

v1.79 (20070228) (internal):

• Bugfix: the link to toggle the extra user info (real name, email address...) in the account list required 2 initial clicks to activate.

v1.78 (20070208) (internal):

• Text strings for various messages (account disabled, invalid username/password/etc) are now customizable.
• New option to prevent the password-reset feature from revealing whether a username exists or not.

v1.77 (20070205) (internal):

• New option to disable the password reset feature.

v1.76 (20070201) (internal):

• The title setting is now two separate settings for the browser window titlebar and the title appearing in the body of the page itself.
• Changed the name of the "members" group to "member" to be consistent with "public" and "admin" (i.e. singular instead of plural).
• New security options (sleep on failed logins, account lockout, IP address restriction).

v1.75 (20070122) (internal):

• Changed the default settings for multiple simultaneous logins and idle timeouts.

v1.74 (20070116) (internal):

• Bugfix: random salt values consisted of the same character repeated over and over.

v1.73 (20070112) (internal):

• Separate prefs file now uses the same syntax as the prefs at the top of userbase.cgi (i.e. it requires proper Perl syntax).
• Now uses a database backend instead of flat files.
• Now supports unlimited groups of users in addition to unlimited individual user accounts.
• User accounts can now include a real name and an email address.
• New option to prevent multiple simultaneous logins by the same username.
• New option to automatically timeout idle login sessions after a period of inactivity.
• It's now possible to specify header and footer files that UserBase will include in its output.  This is normally much better handled by calling UserBase via PHP or SSI (the latter in a *.shtml file), but on some especially retarded servers (which is to say IIS 6+) that's not always possible.
• Various important security improvements to strengthen the security model; these are not bugfixes, but changes to the way we handle authentication and session management.
• Users can now reset their password and have the new password automatically emailed to them without the webmaster's intervention.

v1.58 (20061221) (internal):

• Renamed $PREF{UserBase_url_short} to $PREF{login_url}.
• Changed a hard-coded /cgi-bin/userbase... to $ENV{SCRIPT_NAME}.

v1.57 (20061211) (internal):

• Bugfix: previous update to make usernames case-sensitive actually broke logins in some cases.

v1.56 (20061121) (internal):

• Usernames are now case sensitive upon login (i.e. in process_new_login() and check_if_logged_in()).  This is so that the case of the user's logged-in username always matches FileChucker's userdir name, which is case sensitive.  We still perform a case-insensitive lookup when checking if a username is already taken before creating a new account, so that only one version (regardless of case) of any username can exist.

v1.55 (20060912) (internal):

• Moved the display of the logged-in username to the footer
• Added some default top-margins to the footer elements
• Separate prefs file now supports copying-and-pasting the prefs section from the top of the script without removing the programming syntax.
• Title is no longer automatically wrapped in an H1 (the H1 tags were moved into the pref definition, i.e. no longer hard-coded).

v1.54 (20060831) (internal):

• Manually create the REQUEST_URI env var if DNE (because IIS is garbage).
• Use a meta-refresh instead of print Location: in some cases (because IIS is garbage).
• Try to set DOCROOT from PATH_* (because IIS is garbage).

v1.53 (20060803) (internal):

• Added new "Logged Out" page that explicitly says "You are logged out" rather than automatically redirecting back to the page we came from.  Instead we now provide a link to that page.
• Added the ability to include %%username%% within the auto-redirect URLs that can be set for login, logout, etc., so each user can be sent to a unique destination.

v1.52 (20060614):

• Added the following new PREFs to allow automatic redirection when a user logs in or out:

  	on_member_login_redirect_to
  	on_member_logout_redirect_to
  
  	on_admin_login_redirect_to
  	on_admin_logout_redirect_to
  
  	on_failed_login_redirect_to
  
  	always_redirect_members_to
  	always_redirect_admins_to
  

v1.50 (20060612):

• Merged UserBase's 4 files into a single file to simplify installation and configuration.

v1.22 (20060527):

• Further conditional-docroot-prefix tweaking; moved it from the end of load_commonfuncs_prefs() (in enc_common_functions.pl) to the top of the load_userlist() function, which is the only place in common_funcs where it's needed.

v1.21 (20060526, internal):

• Yet more fixes for the situation where cgi-bin is configured outside of the docroot.  In the load_userlist() function in the enc_common_functions.pl file, removed the hard-coded DOCROOT prefix from the userlist files.  And in the load_commonfuncs_prefs() sub in the enc_common_functions.pl file, added the proper conditional prefixing of the docroot onto the userbase data directory.

v1.20 (20060417, internal):

• Added PREFs common_prefs_file and common_prefs_file_is_in_docroot to userbase_prefs.txt.  Previously they were hard-coded in userbase.cgi; they were always PREFs, but seemed infrequently changed so we were trying to not clutter the userbase_prefs.txt file with them.  But there are enough servers where cgi-bin is not within the docroot to necessitate having these easily adjustable.
• Edited enc_common_functions.pl to make it honor the above prefs instead of always using the hard-coded value for common_prefs_file.  This apparently got overlooked before due to the relative rarity of servers using other than the default setup.
• Moved the DOCROOT pref from enc_common_prefs.txt to userbase_prefs.txt (it does no good in enc_common_prefs.txt since if we can read that, we already have the correct DOCROOT value).

v1.15 (20060331, internal):

• Added new PREF custom_css_section, so custom styling can be applied without having to modify the code itself, simplifying upgrades.
• Implemented new error-code setup so that when an error occurs during a POST, we can redirect thereby still displaying the error message within the site's header/footer layout.
• Added new PREF strangers_can_add_members, for sites that want their users to be able to create their own usernames.

v1.10 (20060320):

• Bugfix: UserBase automatically sends the user back to the page they came from after logging in.  For example, if they tried to visit a FileChucker installation that requires them to log in, and they clicked on the "you must log in first" link which took them to UserBase, then after logging in UserBase would automatically send them back to FileChucker.  The bug is that we were doing this even if the referring page was not some webapp on the same site as UserBase.  So for example if a user followed a link from encodable.com/userbase/ to the UserBase installation on encdemo.com, then after logging in they'd get sent back to encodable.com/userbase/.  That obviously doesn't make sense since they logged into encdemo.com, not encodable.com.  So now we only redirect back to the referring page if it's on the same site where UserBase is installed.
  
  This is a fairly insignificant bug: it has no ill effects (other than perhaps the user being slightly confused at being sent back to that referring page, which would be quickly remedied after they clicked on the link back to UserBase and were logged in this time), and it would only occur if you had two separate websites, one of which linked directly to the UserBase login page on the other.

v1.05 (20060315):

• Some general cleaning-up and providing more explanation for the user-adjustable PREFs.

v1.00 (20060314):

• First public release (after about 4 years of use on various Encodable websites).