[isf-wifidog] User authentication and information design (was: Ajout des données nom et prénom )

[Benoit Grégoire]

On January 26, 2006 04:29 pm, Michael Lenczner wrote:
> "The real name will never be stored in the users table."
>
> hey Ben - could you make the reasoning behind this clear?  Is it
> solely a questin of philosophy towards anonymity.  Or is there any
> technical reason why supporting this would not be the right way of
> doing it.
>
> I'm thinking of lots of groups that can't use wifidog if we put this
> level of anonymity on it.  there might be business or things like
> schools or libraries that would need to know who is using their
> network.

I totally agree, buy putting this info in the user's table will make the 
system less flexible, not more flexible.

> Just want to establish whether we are refusing to implement that
> feature/modification for philosophical grounds or philosophical AND
> technical grounds.

I'm glad you asked, even if I didn't really have the time to write this long  
email....

I can find a number of valid technical reasons, but I have to admit the 
phisophical reasons would be enough for me.  However, this is the wifidog 
project, not ISF, and one of the things we promised in London is that we 
would allow other groups to experiment with other models/philosophies.  
However, we want to keep it easy to keep OUR philosophy.

Putting this data in the user's table would be a bad example and force me to 
reject patches in the future on philosophical grounds alone (jeopardises the 
ISF model).  That would suck, for everyone.

The solution is to put the information elsewhere.  There are actually two 
different problems.  One is handling publically available user information 
managed by wifidog (profiles, preferences, etc).  The other is handling the 
information provided by/needed by the Authenticator.

The goal is to separate the information in the following three categories, and 
keep this separation right down to the schema for design clarity reasons:

1- Wifidog technical info, and primary users table: Technically required or 
generated  information, and all the information necessary for communicating 
with the appropriate authenticator.  In the long run, it shouldn't even 
contain the username and password.

2- Wifidog user changeable info:  This would contain all optional, unverified, 
user provided information, including publically available information.  It 
may actually be may be supplemented by user_content, or other such tables.

3- Authenticator specific tables:  All information managed by an 
authenticator.  For example (this isn't currently the case), the email adress 
in the standard authentication should be here.  For some authenticators, this 
table may not even exist (RADIUS comes to mind).  For others, it may contain 
much more information (Someone using wifidog in a more commercial context).

This way, should a group decide to make the real name mandatory, it's logical 
that they wouldn't let the user change this information.  This should 
probably be handled at the wifidog/authenticator interface, not in profiles.  
Should that information have to be public, the simple way would probably be 
to provide a getUserPublicInfo() API in the Authenticators.  Pushing it even 
further, we could even provide an edit interface abstraction, for even more 
flexibility.

There will be (as soon as we finish user profiles) a User::getListUI() method, 
which will be used when displaying lists of users (on the protal, in 
statistics, and in any other features we may decide to implement).  That way, 
the system won't become a mess of spagetti code everytime someone whant to 
experiment with a different social model.

At far as I could see, all the models I ever heard would fit in that general 
architecture. Off course, the current AuthenticatorLocalUser hasn't been 
fully abstracted in that model yet, as there was little incentive to do the 
actual work. 
-- 
Benoit Grégoire, http://benoitg.coeus.ca/
-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 189 octets
Desc: non disponible
Url: http://listes.ilesansfil.org/pipermail/wifidog/attachments/20060126/919193e7/attachment.pgp