Page Blocks

Hosting sponsored by:

Point In Space

ToolKit Description

User Authentication

One of the most difficult systems to design and maintain in a restricted access web site is that of user authentication (validating a user's name & password) and authorization (assigning of access and editing rights).

Both of these needs are managed with a set of standardized tools and practices in the pageblocks framework. The authentication framework includes a baseline database for storing user profiles and access rights. Access rights for the application are defined using a simple configuration file.

For many sites a single set of tables with even a single profile table and a single user object will work fine. This illustration shows a single table set for permissions and filters, but with several unique profile tables for different types of users.

Some applications where different user types may need very different profile or permissions needs can implement completely separate data tables and user objects. This illustration shows that there can be more than one user object so it is easier to program for the differences in needs.

The features of all these components are automatically fused into the user object which automatically restored for each page.

The user permissions system adapts to changes in the configuration file. without requiring that existing users be updated unless they specifically need to use the new permissions.

User profiles can also be used to automate filtering of database queries based on matching user profile data with a field in the data set. For example, web sites run with multiple sub-domain names can have user profiles stamped with sub-domain names to limit queries to records matching only that domain name. Company departments, workgroups, or membership levels, or other such sets of users can be also be accomodated. When users are defined, the table, field, value, and field operator can be determined through form selections and written to the user's profile. This profile filter is retrieved and incorporated into queries automatically so the programmer doesn't have to define it with each database search.

Best known practices are used to maintain high levels of security. All logins (successful and failed) are logged, passwords are stored in MD5 format, and a number of programming conventions are used to maximize the difficulty of password cracking. Sessions minimize exposure of user profile information, and session IDs can be configured to change with every page load to significantly decrease the risk of session hijacking.

User Administration

A user database and administration pages are already prewritten and can be used as is or expanded to suit application needs.

You can view other admin pages with these links:
Authentication Form
Privileges Form
Filters Form
Summary Page

Password Management

Several features are available to manage logins and passwords including login lockout after sequential failed tries, use-once passwords, required password renewal after X days, a password history so recent passwords aren't reused, and more. The flow chart below illustrates the login process and its options:


Using the User Object

With a user system all set up, app code has infinite control over authorization. Permissions are ACL-like with the definition of modules and permissions. Each module can have unique permissions.

In app code you'd write something like this:

if: $fw_user->(getPrivilege:'products_update') == 'Y';
  ..... allowed .....
else;
  $fw_appError->(insert:'5011' = 'not authorized');
/if;

where 'products' is the module and 'update' is the specific permission. Permissions can be operational like 'update' or 'view,' or they can be descriptive like 'executive' or 'manager.' they're simply flags, and the application code defines where and how they are used.

The application can also get user profile data using:

<p>Your phone is: [$fw_user->(getProfile:'userPhone')]</p>

Visit the fwp_user reference page for more details.


© 2002-2010, pageblocks.org