View Issue Details

IDProjectCategoryView StatusLast Update
0020543mantisbtauthenticationpublic2016-06-12 00:42
ReportervboctorAssigned Tovboctor 
Status closedResolutionfixed 
Product Version1.3.0-rc.1 
Target Version1.3.0-rc.2Fixed in Version1.3.0-rc.2 
Summary0020543: 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 can match against the first one return (ideally the highest access level).
  • We can match against the first one that succeeds the password check.
  • We can just fail the request and require a username in such case.

We should also strive to enforce by default uniqueness of email addresses.

TagsNo tags attached.




2016-01-26 19:10

developer   ~0052394

If email is to be used as user identifier, i feel that it should be unique.
And that, in my opinion, can be a more disrupting change than skipping on this feature...

Non unique email may have a use case for notification management, as different users may want to receive emails in a common inbox.
So maybe this could be solved by having a unique user email (used for authentication, password management, etc), and >0 non unique recipient emails, used for notifications.

Another view:
Having separate concepts for:

  • system user, representing the person identification, as the agent, profile, and data within the application.
  • account login, representing how the agent logs in the system.
    Account login may be user id+password, a uniqe email+password, openid, etc


2016-01-26 22:16

manager   ~0052395

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:

  • Notifications
  • Reset password

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:

  1. Provide an option to enforce email uniqueness for newly created accounts within existing instances / new MantisBT installations (ideally ON by default). But can be set to OFF. People who do need it will know because of the error message will drive them to configure.
  2. user_get_id_by_email() should have a predictable behavior when email is used multiple times, e.g. prefer enabled accounts over disabled, prefer higher access level over lower ones.
  3. Enable login via email in general (leveraging criteria in 2), or at least if it is unique.

I don't see a downside for the above. I think it is an improvement over where we are at today.



2016-01-27 02:57

manager   ~0052401

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.



2016-01-27 06:47

developer   ~0052404

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.



2016-01-27 13:08

developer   ~0052410

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:

  • adding support for additional emails, I think this has been requested from time to time. It would allow using one or more separate email for notifications, which dont need to be unique, and would not serve for authentication purpose. (Note that probably wouldnt need to be searchable either).
  • Upgrade can keep current emails that are unique, as main email. Non unique emails are moved to the prevously commented alternate email.
  • A warning on user login that recommend to fill main email if its empty.


2016-01-29 01:15

manager   ~0052427


Related Changesets

MantisBT: issue20543_login_by_email 7a0334de

2016-01-29 01:11:51


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

Fixes 0020543
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

Issue History

Date Modified Username Field Change
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