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
| Parameter | Definition |
|---|
| NotifyAdminOfNewRegistrationsP | Administrator is notified of all new registrations |
| NewRegistrationEmailAddress | Where to send administrator notifications of registration (defaults to SystemOwner) |
| EmailRegistrationConfirmationToUserP | New user is sent an email confirmation |
| RegistrationRequiresApprovalP | Administrator must approve before user is authorized |
| RegistrationRequiresEmailVerificationP | User must verify email before he/she is authorized |
| RegistrationProvidesRandomPasswordP | System will generate a random password for the user |
| EncryptPasswordsInDBP | Encrypt the passwords inside the database |
| EmailForgottenPasswordP | Provide (and allow) an interface for the user to ask for forgotten password sent via email |
| EmailRandomPasswordWhenForgottenP | If the user requests a password reminder, generate a random password |
| EmailChangedPasswordP | If the admin changes the user's password, allow this to be sent to the user |
| AllowPersistentLoginP | Give an option for persistent cookies to store login information |
| PersistentLoginDefaultP | If persistent cookies are allowed, make it default on |
| LastVisitCookiesEnabledP | Enable the cookie-backed tracking system |
| LastVisitExpiration | Maximum visit length for session tracking |
| NeedCookieChainP | Set a cookie on more than 1 hostname (i.e., is your site a typical "foobar.com" and "www.foobar.com" case) | |
| CookieChainFirstHostName=yourdomain.com | First domain name in the cookie chain |
| CookieChainSecondHostName=www.yourdomain.com | Second 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
