Forum OpenACS Q&A: usernabme instead of emails for login

Collapse
1: usernabme instead of emails for login
Posted by Hamilton Chua on 10/25/01 04:38 AM
Hi all,

I am using OpenACS4.2 to develope a web application for someone. It
seems that instead of an email address these people would like to use
a username to login to the web application.

I noticed that I can create a custom registration form and use
ad_user_new and pass it the pertinent values. In so doing, I noticed
that I can pass a username to $email and ACS won't complain.
Furthermore, when I login using the username - the system accepts it
without complaining that it is not an email address.

I am delighted to discover that ACS does not complain but I am sure
there are lots of repurcussions - i beleive that everything from
alerts to lost passwords depend on the login name being an email
address.

Right now though, the important functionality is being able to
retreive forgotten passwords though we do plan to use alerts and the
other stuff later on.

My question is - Is it wise to use usernames instead of the email
address ? What are othe repurcussions that I should be aware of ?

Many Thanks

Collapse
2: Response to usernabme instead of emails for login (response to 1)
Posted by Jon Griffin on 10/25/01 04:46 AM
I have done it and it is a tedious pain in the A*%. I believe there is another thread about this.
Collapse
3: Response to usernabme instead of emails for login (response to 1)
Posted by David Walker on 10/25/01 05:04 AM
We added another field to the users table and altered the files in
/register to look at that field instead of email address as the user
name.  That way everything else stays intact.  Note that this method
still requires a unique email address for each user.
Collapse
4: Response to usernabme instead of emails for login (response to 1)
Posted by Hamilton Chua on 10/25/01 05:14 AM
that's absolutely wonderful, what is this field ? I am taking a look
a the register/ files right now
Collapse
5: Response to username instead of emails for login (response to 1)
Posted by David Walker on 10/25/01 05:21 AM
It was a specific field for the client but the screen_name field
might be a good one to use for that.
Collapse
6: Response to usernabme instead of emails for login (response to 1)
Posted by Hamilton Chua on 10/25/01 06:12 AM
Yeah, screen name. I modified user-login.tcl 

set email [string tolower $email]

if { ![db_0or1row user_login_user_id_from_email {
    select user_id, member_state, email_verified_p
    from cc_users
    where email = :email}] } {
     
    # HG Chua- we also need to check screen name
    if { ![db_0or1row user_login_user_id_from_username {select 
user_id, member_state, email_verified_p from cc_users where 
screen_name = :email}] } {

	    # The user is not in the database. Redirect to 
user-new.tcl so the user can register.
	    ad_set_client_property -persistent "f" register password 
$password
	    ad_returnredirect "user-new?[ad_export_vars { email 
return_url persistent_cookie_p }]"
	    return
    }
}


To check screen names in addition to email. So a user can essentially log in using his/her screen name and email address. what do you think guys ?
Collapse
7: Response to usernabme instead of emails for login (response to 1)
Posted by defunct defunct on 10/25/01 12:08 PM
We've had a similar problem with this pertaining to mobile numbers.

Most of what we deploy are systems where the mobile phone number is the primary identifier....

We've used a couple of methods to circumnavigate this including such cheesy tricks as:

-Creating dummy email addresses such as +mailto:4478189938@system.com
Which is neat enough for systems where email isn't really required at all. Its fairly straightforward to alter the interfaces etc.. so they assume when a number comes in it is actually <number>@<email>

-Inheriting the user objects to create a new mobile_user... If a user doesn't want an email we assume a similar dummy name creation, and hen create our own mobile_user_login type funtions that the pass through to the underlying registration functions...

If you've essentially 'inherited' the existing tables as per the acs method then you don't disrupt the underlying operations.. all you need do is add you specific indetifier processing on top...

My understanding was from aD 4.2 that this was the intended way to use the toolkit and the purpose of the entire acs_objects approach...

But, is there a case for a more fundemental change to the core to support different identifier types?

Of course the issues arises that mobile numbers and emails are globally unique. Screen names are not... you end up having to implement one of those awful

'The name you chose has been taken... what about Blob99784?'

Yuk ;o)

Collapse
8: Response to usernabme instead of emails for login (response to 1)
Posted by Jon Griffin on 10/25/01 04:31 PM
I will dig up my notes, and explain as much as I remembered to write down as far as a complete revamp not using email.
Collapse
9: Response to username instead of emails for login (response to 1)
Posted by Hamilton Chua on 10/25/01 04:49 PM
Thanks everyone for responding. . .  Since Jon will be doing some
digging up on his notes on the subject. I guess it's fair that I
share what else I had to implement aside from changing the
user-login.tcl file in packages/acs-subsite.

I must admit though that this is rather awkward specially since I am
working on OpenACS 4.2.

I did not need to change register.tcl (for now at least, though it
seems that I will have to later on) but I had to modify the edit
feature to ensure that users who update their profile enter a unique
screen name.

Aside from the regular register.tcl - I created my own registration
page, because we needed additional input aside from just the
password, email and secret questions/answers.

I am still looking at all the sides and I do very much look forward
to Jon's notes and everyone else's input.

And yes, at a certain point I also did think of appending an
mailto:'@mypage.com'; .

Agian, Many Thanks

Collapse
10: Response to usernabme instead of emails for login (response to 1)
Posted by Don Baccus on 10/25/01 08:34 PM
Simon's approach seems very generalized - subtype the user class and add  a new authentication field there, and drop in new registration/login pages that match.

Of course, some folks may want systems that don't require e-mail addresses at all, which I think is where Jon's headed with his comments.

Collapse
11: Response to usernabme instead of emails for login (response to 1)
Posted by Jon Griffin on 10/26/01 02:42 AM
BTW, This post should be in the ACS4 bboard.

I added preliminary (very) documentation for eliminating email from a 4.x install at: http://jongriffin.com/static/openacs/no-email/no-email

PLEASE NOTE this is only from memory. If there is enough interest I will update it to be more complete.