Forum OpenACS Development: Re: Elimination of email as center of OACS registration.

A couple of comments: First, I like using email as a user's login id, simply because it's easier to remember because it's more likely to be unique than a screen name I compete for with everyone else who uses the site. However, in practice, I've found several problems with using email as the unique login:

• In these days of free email accounts flooded with spam, my users tend to forget which of their many email address they used to register, and will re-register. This totally messes up all the groups memberships and associated permissions that we've set up for them.
• A solution to the "forgot my email" problem is to let the user store multiple email addresses in his/her contact record (work, personal, whatever), and check against all of these emails for user login. Of course, we don't have a way to do that, and I had hacked together a user directory app for a site that needed it and modified the login scripts to check against all emails and hope for a match, but it is not fit for human consumption (it was for an ACS 4.2 site).
• Also, in practice, it's nice to be able to create all your parties and set up groups and permissions before they ever log in, rather than waiting for them to register and giving them permissions afterward. However, this exposes a problem with the way OpenACS works today, in that parties cannot become users, because person.new() will fail the unique constraint for email. (see Bug #354 in the bugtracker for the way I worked around this problem). So the flow of parties becoming persons becoming users doesn't actually work right now.
• I've also wished for an alternative to using email address as logins, in order to support people that don't have emails. For example, I've built a site for my church, and I'd like to do some personalized, kid-centric content, but I can't count on children having email addresses. Email should go to the parent, but the login should belong to the child. I've also got some people sharing email addresses (i.e. the family email), so email to identify individuals also breaks down in that case.

Now for my suggestions:

• a quick and dirty change would be use the "screen_name" field in the users table as the login key rather than email in parties. This would be minimal change, but not really "fixing" the data model. Then when the user provides an email address, we can check to see if that party already exists change its party_id to the user_id
• A more comprehensive solution would be to implement a more complete user directory/contact info datamodel (maybe HR-XML, maybe something like Outlook or Palm has), then generalize the authentication scheme to correlate the person trying to login with a record in the database. Basically, login is a two stage process: first, you ask the user for enough information (email, screen name, first/last name and birthday, phone-number, etc) to get it down to one contact record, and therefore one password, and then authenticate this person against it. It may have to be interactive (multiple people with the same name, or email wasn't found, try another) and redirect to registration if no matching record exists.

Maybe we should make changes that would fit with Lars' external authentication module which would still require a generalized way of asking for specific info so we can authenticate the user, either using external auth or entirely within ACS.