Before development of the Web Interface, a Visual Identity Guide (VIG) will be required. This guide will contain the basic style elements to ensure that all pages on the User Interface are visually and thematically consistent with each other and with the general GPFN web site.
The Visual Identity Guide will also contain directives concerning how users will navigate around the pages as well as how linkages outside the UMS pages back to the GPFN general web site will be incorporated.
In addition to the VIG, web developers will require a common set of resources such as icons, navigation bar graphics, template files and HTML Style. Developing the VIG and the other components will be the duty of the GPFN webmaster.
All System Configuration APIs must be intrinsically distrustful of their calling functions. This prevents a potential malefactor from directly calling these programs while masquerading as coming from a valid user. Such a masquerade could be successful if the API did not verify the authenticity of the caller on its own.
This distrust is managed by creating a virtual domain within the webserver for the UMS. The virtual domain along with its libraries and system configuration APIs will run under a distinct set of user and group permissions.
The Password Change API is responsible to ensure that the username and old password successfully authenticate the user. Only if the user is verified in this way is the new password checked for hardness according to the system configuration (normally using the cracklib libraries), then using a suid program, this API effects the password change on the system.
The Mail Forwarding API authenticates the user and if authenticated, allows the user to review, change or set the contents of their home .forward file.
The Mail Filtering API can perform many functions. For the purpose of this application, it copies a system .procmailrc template file into the user’s home account, thus effecting spam control. Again, the API must authenticate the user before effecting these changes.
The Disk Quota API authenticates the user and once authenticated, returns the user’s current quota values for display back to the user via a CGI script.
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 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.
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:
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.