ArsDigita Archives
 
 
   
 
spacer

User Registration and Access Control

part of the ArsDigita Community System by Tracy Adams

The Big Picture

We want to let publishers decide how many hurdles and approvals a user must get through before being authorized to use the system.

Medium Size Picture

A typical public access web site might simply ask for your name and email to give you a unique identity and for user tracking. Sites concerned about personal misrepresentation will require an email verification step. Your active membership base will be in flux as leave and other you restrict. For sensitive applications (ie - medical tracking systems), access control becomes more serious. Here, required options include approval systems, encrypting passwords in the database. This module allows a site administrator to set up an access control system by choosing from a palette of options.

To simplify the user authentication, a finite state machine is used to control the user's state. Users with access to the system have a user_state of 'authorized'.

Registration Options

ParameterDefinition
NotifyAdminOfNewRegistrationsPAdministrator is notified of all new registrations
NewRegistrationEmailAddressWhere to send administrator notifications of registration (defaults to SystemOwner)
EmailRegistrationConfirmationToUserPNew user is sent an email confirmation
RegistrationRequiresApprovalPAdministrator must approve before user is authorized
RegistrationRequiresEmailVerificationPUser must verify email before he/she is authorized
RegistrationProvidesRandomPasswordPSystem will generate a random password for the user
EncryptPasswordsInDBPEncrypt the passwords inside the database
EmailForgottenPasswordPProvide (and allow) an interface for the user to ask for forgotten password sent via email
EmailRandomPasswordWhenForgottenPIf the user requests a password reminder, generate a random password
EmailChangedPasswordPIf the admin changes the user's password, allow this to be sent to the user
AllowPersistentLoginPGive an option for persistent cookies to store login information
PersistentLoginDefaultPIf persistent cookies are allowed, make it default on
LastVisitCookiesEnabledPEnable the cookie-backed tracking system
LastVisitExpirationMaximum visit length for session tracking
NeedCookieChainPSet a cookie on more than 1 hostname (i.e., is your site a typical "foobar.com" and "www.foobar.com" case)
CookieChainFirstHostName=yourdomain.comFirst domain name in the cookie chain
CookieChainSecondHostName=www.yourdomain.comSecond domain name in the cookie chain

Registration Finite State Machine

A user must be in the authorized state to have access to the system. Prior to approval, users must pass "Need Email Verification" and "Need Admin Approval" tests. Users may be "Rejected" at an stage prior to the "Authorized" state. One a user is "Authorized", they may be "Deleted" or "Banned". "Deleted" users may self-activate.

			Not a user
		     	     |	
		             V
	           Need Email Verification          Rejected (via any
	             Need Admin Approval             pre-authorization state)
   			     |				
   		   	     |  	                
Need admin approval<--------- ------------->Need email verification 
   |						        |
   |                 		 			|
   --------------------->Authorized<---------------------                       
                             |
        		     |		  
 Banned------------><-------- ------><---------------Deleted
Following ACS convention, states in the database are represented by lowercase tokens, sometimes with underscores:

user_state		varchar(100) 
  check(user_state in ('need_email_verification_and_admin_approv', 
                       'need_admin_approv', 
                       'need_email_verification', 
                       'rejected', 
                       'authorized', 
		       'banned', 
		       'deleted'))

Restricting to authorized users

The users_active view contains only authorized users:
--- users who are not deleted or banned 
--- (not that this does not have approval system)

create or replace view users_active
as select * from users 
 where user_state = 'authorized';

The users_spammable view contains active users that may be spammed:

create or replace view users_spammable
as select u.* from users u, users_preferences up
 where u.user_id = up.user_id(+)
 and (on_vacation_until is null or 
      on_vacation_until < sysdate)
 and user_state = 'authorized'
 and (email_bouncing_p is null or email_bouncing_p = 'f')
 and (dont_spam_me_p is null or dont_spam_me_p = 'f');
The users_alertable view contains active users that wish to receive alerts:
create or replace view users_alertable
as
select * 
 from users 
 where (on_vacation_until is null or 
        on_vacation_until < sysdate)
 and user_state = 'authorized'
 and (email_bouncing_p is null or email_bouncing_p = 'f');

Future Improvements

  • Add options to force user to change password after x days.

teadams@mit.edu
spacer