The Shared Library functions include all functions and methods used by two or more components of the system. It will include user authentication and managing of session credentials.

These functions will involve setting and retrieving cookies on the user’s browser, writing to and retrieving session values from the relational database, and managing Object Oriented PERL constructs and entities.

User Authentication

User authentication involves comparing the username supplied on a web form with the existence of the username on the system then comparing the password supplied on the form with the password maintained for the account on the system.

On a modern Linux system, Pluggable Authentication Modules, or PAM, supports user PAM supported libraries and applications are available on the Internet to be used as a template in constructing a custom authentication package.

For the UMS, a web form will request a user to input his username and password. PAM will then authenticate this user. If the user is successfully authenticated, a session  token will be created for the user. This token will have an expiry date one hour into the future.

Authenticating GPFN volunteers is a slightly different matter. A GPFN volunteer is not simply a user, but rather a user with increased permissions to the system this system  may not be suitable for volunteers. As well, volunteers may not want to use their  system password to authenticate themselves to the UMS. Instead, they may want to use a password specific to the UMS.

For this reason, authenticating GPFN volunteers will use the htaccess and htpasswd functions inherent in the Apache web server. Web pages and CGI scripts specific to volunteers will be in a separate directory under which the web server will apply  access controls.

Session Credentials

Once the system authenticates a user, the libraries will have to manage session persistence for the user. To effect this persistence, the libraries will have their own database in the RDBMS. When a user is authenticated, a session token will be created composed of the username, the access level, the session creation timestamp, and a unique pseudo-random session ID. This token is inserted into the database and a cookie with this session token will be sent back to the user’s browser.

From then on, any calls by the user to a page on the system will return the cookie. This cookie is matched with the cookie in the database. If a match exists, then the user is the holder of a currently valid session. Any of the following conditions indicates that the session is not currently valid:

1. There is no corresponding session token in the database matching the session token contained in the supplied cookie.
2. There is no cookie containing a session token sent back by the web browser.
3. The session tokens for this user between the database and the sent  cookie do not match.
4. If the timestamp of the cookie as recorded in the database exceeds the current timestamp less the expiry period of the session.

In any of these cases, the user is redirected back to the login page with the current pages’ URL stored in the QUERY_STRING for re-authentication and the session token is deleted from the database and the cookie. Once re-authenticated, the stored URL can be used to return the user to the page they were viewing before the authentication failure.