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

This should also be configurable ... a large percentage of our  site developers don't seem to have a problem with e-mail being required.  If e-mail verification is required for registration, then they'll need to provide an e-mail address and if you have a separate login name and e-mail address it forces the registering user to add two pieces of information where today one suffices.

(IMO it's rather silly of people to share a mailbox in the 21st century when you can get free webmail at dozens of sites and even free IMAP accounts at some.  Plus all the major ISPs offer multiple boxes per account...)

Silly or not many people still share mailboxes. That is a fact of life.

One of the reasons I started getting serious about this is that my changes for HR-XML compatibility and contacts become kludges when you are required to have a unique address for each party. (Another reason is a friends site that wants anonomity for its users).

I will flesh this out some more tomorrow and throw a preliminary patch together. Be warned, it requires PG 7.3 as I do some drop columns etc that don't work in earlier versions.

Randy,

As far as getting other information, I would just have a link that requests the info. It seems like you are asking for contact info and if you are using PG you can look at the packages on my site. The Oracle versions are just about done and I hope to have them tested by the weekend.

Anyway, we need to do this for one of our sites, and I though adding login_id (nickname, screenname, whatever you want to call it) to parties as well. Would this be cool with the core team ?

• 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.

Anyway .... bottom line is we need

1. to allow for the e-mail requirement for those who still like it.

2. to allow for arbitrary user names for those who like that and, as Lars points out, for working with external authentication servers.

3. if a site decides to allow for arbitrary user names it should still be possible to demand an e-mail address in order to allow for e-mail verification of registrations to cut down on bogus spamish registrations.

4. If we get rid of the unique e-mail restriction, doesn't this make it possible in scenario #3 for someone to set up one mail account with a 'bot answering it, then use that one mail account to register and verify an arbitrary number of users with login names like "a", "b", etc?  Imagine for instance that Greenpeace decides to move its discussion server from Zope to OpenACS, not entirely far-fetched since Bruno's been mumbling about it for over a year.  Greenpeace is an organization that's likely to be a target for vandals.  We need to think in these terms ...

I had thought there was some discussion in the past about making login subsite aware. No new info would be supplied by the user, but a separate subsite or domain field would be used to create a unique user account.

If this were done, you could possibly use this domain, or some configurable domain as the default following the @. If no @ were supplied, the default would be added to the end.

However, in this case, you would still want a real email address for the user.

The main datamodel problem is that in the real world, email addresses are not unique enough to distinguish users, or even accounts. Also, users are often wary of providing a real email address until they become familiar with a site.

Maybe if users could create an account without an email, and somehow we could use the user_id cookie to remind them on occasion of the importance of providing an email address. This might include some function that would also notify the user when their email bounces (by noticing the bounced email). Email addresses are vital maintainance of user communities, and users who do not provide them are not really contributing to the community in the long term.

If the site also included a forwarding service for the local subsite account, i.e.:

tom.jackson@subsite.openacs.org --> tom@example.com