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

[Michael Lenczner]

I appreciate your taking the time to answer that, benoit.  Thank you very much.

Mike

On 1/26/06, Benoit Grégoire <bock at step.polymtl.ca> wrote:
> 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/
>
>
>