This is all probably indicative of a need to distinguish the ‘user
profile’ information (name, birthday, favourite colour) from the
actual authentication information (id & password/phrase).
Perhaps the real way forward is either/or/both of:
a) removing the extraneous information (currently the name and email*)
from the authentication system, and
b) giving developers a fairly intuitive means of defining their own
validations on the id field - or a means of selecting between a few
existing ones (login, email address, something else…)
The stealth-launched new site (http://rails-engines.org) has a link to
the Trac system.
Someone submit a ticket, close your eyes and click the heels of your
ruby slippers three times, and perhaps it might get done
james
note that removing the guarantee that one field will contain a valid
email address means that email notification has to be reworked too.
Short of hacking the code apart, is there a method making the
login_engine authenticate against email address rather than username?
Hi all,
Thanks for your responses. I’ve managed to make it work by just simply
changing most instances of the ‘login’ variable to ‘email’ and
removing/tweaking the validation lines. The code isn’t very complex, and
a bit of following it all through did me some good.
In a future version, a flag in the config would be ideal, allowing you
to auth against whatever field you wanted.
Login_engine is great work though - saved me a lot of time writing my
own system!
I was not inferring that he delete the login column and field, rather to
remove the email field and use the login field for both the email and
username.
I see under the validation that you would likely have to extend the
length_of below for the login field to more adequately compensate for
the
longer email addresses.
You still want to ensure that the email is unique, present,
So I suggest only modifying the following line in
LoginEngine::Authenticated
to the following.