View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0020543||mantisbt||authentication||public||2016-01-25 21:46||2016-06-12 00:42|
|Target Version||1.3.0-rc.2||Fixed in Version||1.3.0-rc.2|
|Summary||0020543: Login using username or email address|
Often services offer users the ability to login by providing their username or their email address in addition to their password and use that to login. I think often people are used to logging in using email addresses and often get confused about logging in with the username. That is specially true when they are new to MantisBT.
If we fail to find the user by the provided "username", we can have another lookup for user by email address and log them in if they match the password.
As for the scenario where an email address is used multiple times:
We should also strive to enforce by default uniqueness of email addresses.
|Tags||No tags attached.|
If email is to be used as user identifier, i feel that it should be unique.
Non unique email may have a use case for notification management, as different users may want to receive emails in a common inbox.
If you look into what is common is that there is a single email per user that is used for notifications and authentication. In some cases, there may be aliases, but these are just used for scenarios like social networking scenarios like facebook and linkedin. Or in aliasing scenarios like github where users may want to claim ownership of multiple emails address to link such commits to their user account.
Note that even if we enforce uniqueness, there is also the possibility of using the + approach to have test accounts or two accounts that are necessary to point to same inbox.
If you think about scenarios we think about today. They are:
For notifications, it is OK for share, but for reset password, having a shared mailbox where such resets fall is kind of strange and breaks the identity concept associated with the user account that reset.
In order not to try to boil the ocean and to be paralyzed by the corner cases. We have two options:
I don't see a downside for the above. I think it is an improvement over where we are at today.
Another option for point 2 above, is to have user_get_ids_by_email() that returns enabled accounts sorted by access level (DESC) and return the first one that matches the password.
As per 3, we can still decide to only make login via email work when we get a single email address back.
I am fine with the proposed approach, however I think we should allow admins to prevent the fallback to e-mail address identification if they don't want it (e.g. in my previous company, relying on a user ID that can't somehow be related to the user's name was a mandatory requirement from IT security, eg. M123456). I don't really care about the default setting for this.
if email were to be set unique, id say go straight into it and dont add a cofiguration to disable.
For a upgrade path, maybe:
MantisBT: issue20543_login_by_email 7a0334de
2016-01-29 01:11:51Details Diff
|Support login by email address
In addition to login by username and password, this change adds
support for login by email address and password when the following
conditions are true:
- email address is not blank.
- email_login_enabled is ON.
- there is a single enabled email account w/ such email.
|mod - config_defaults_inc.php||Diff File|
|mod - core/authentication_api.php||Diff File|
|mod - core/user_api.php||Diff File|
|mod - docbook/Admin_Guide/en-US/config/email.xml||Diff File|
|2016-01-25 21:46||vboctor||New Issue|
|2016-01-26 19:10||cproensa||Note Added: 0052394|
|2016-01-26 22:16||vboctor||Note Added: 0052395|
|2016-01-27 02:57||vboctor||Note Added: 0052401|
|2016-01-27 06:47||dregad||Note Added: 0052404|
|2016-01-27 13:08||cproensa||Note Added: 0052410|
|2016-01-29 01:15||vboctor||Assigned To||=> vboctor|
|2016-01-29 01:15||vboctor||Status||new => assigned|
|2016-01-29 01:15||vboctor||Note Added: 0052427|
|2016-02-04 11:35||vboctor||Changeset attached||=> MantisBT issue20543_login_by_email 7a0334de|
|2016-02-04 11:35||vboctor||Status||assigned => resolved|
|2016-02-04 11:35||vboctor||Resolution||open => fixed|
|2016-02-04 12:27||vboctor||Target Version||=> 1.3.0-rc.2|
|2016-04-04 11:09||atrol||Fixed in Version||=> 1.3.0-rc.2|
|2016-06-12 00:42||vboctor||Status||resolved => closed|