Nathan Dintenfass wrote:
An alternative perspective is that "theUser" should not know how to
"authenticate" itself.
Rather, you might have an "Authenticator" that knows how to do
everything that has anything to do with authentication, which can be
passed the un/pw.
"theUser" might have some kind of state ("isAuthenticated"), but even
there you might ask the Authenticator (or some other
authentication-related state checker) rather than coupling notions of
authentication with theUser itself.
I read somewhere (I think it's somewhere in the Macromedia coding
guidelines site) that they have three states for authenticatied:
Unauthenticated, remembered (from previous session) and Authenticated
(meaning they've validated credentials this session). I like this idea,
as this lets you remember people for when they're just browsing around,
but can force authetication to do something important... like do a bank
transfer or send email or post on a blog or something along those lines.
I also like the idea of having different Authenticators, which in turn
may take different types of Credentials, such as user/pass, biometric
input, or third party (like passport) or what have you. Probably going
too far for a web app. (Although having different Authenticators would
be good if you have user details stored among different sources).
My 2c.
--
Haikal Saadh, Applications Programmer
Teaching and Learning Support Services
K405, Queensland University of Technology, Kelvin Grove Campus
[EMAIL PROTECTED], 3864 8633
CRICOS No. 00213J
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
