Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Identity] Add ability to UseEmailAsUserName #6613

Closed
HaoK opened this Issue Jan 11, 2019 · 11 comments

Comments

Projects
None yet
5 participants
@HaoK
Copy link
Member

HaoK commented Jan 11, 2019

We've debated this before, but given that this is the normal situation these days, we should probably revisit this and add support to have email be the user name (and iron out all of the issues that come along with that, uniqueness, email confirmation, etc)

See aspnet/Identity#182 for some of the old context, old PR https://github.com/aspnet/Identity/pull/165/files

@HaoK

This comment has been minimized.

Copy link
Member Author

HaoK commented Jan 11, 2019

@blowdart @ajcvickers should this go into 3.0-preview3 or what milestone?

@blowdart

This comment has been minimized.

Copy link
Member

blowdart commented Jan 11, 2019

I'd say Preview3.

@HaoK HaoK added this to the 3.0.0-preview3 milestone Jan 11, 2019

@HaoK

This comment has been minimized.

Copy link
Member Author

HaoK commented Jan 14, 2019

Discussed a bit with @ajcvickers today, current plan is to introduce something like UserNameIsEmail which is a runtime only flag which would have the user manager use the username in any APIs that currently use email, this would also have a sideeffect of implicitly turning on RequireUniqueEmails. Setting one property should also have the effect of setting the other (via identity apis).

One thing we didn't discuss, what happens if they manipulate the poco directly, i.e.

user.Email = "something@foo.com".
user.UserName = "somethingelse@bar.com".

As I currently envision things, this would just end up setting Email to "somethingelse@bar.com" via the user manager which will blast the UserName into the Email property on every save operation. Does that sound reasonable?

@Andrzej-W

This comment has been minimized.

Copy link

Andrzej-W commented Jan 14, 2019

In a new application it is probably OK, but what about old applications? Let's assume we have the following user

user.Email = "john@example.com"
user.UserName = "john"

In that case you should rather copy Email to UserName and inform the user that from now he/she has to use email to login to the service.

@HaoK

This comment has been minimized.

Copy link
Member Author

HaoK commented Jan 15, 2019

Right, I forgot to mention that discussion, this setting will only be meant to be used where the username and email are already the same. It will not normalize or fix the database automatically, users can normalize their old database before turning on this flag which would work, but its not meant to detect any issues. New apps starting in 3.0 would have this set to true explicitly, old apps they would have to opt into this behavior as needed.

@LindaLawton

This comment has been minimized.

Copy link

LindaLawton commented Jan 23, 2019

It will not normalize or fix the database automatically, users can normalize their old database before turning on this flag which would work, but its not meant to detect any issues.

It would be nice if it would at least warn at startup of duplicate emails or UserNames not equal to email. Someone sets this by mistake and they are going to be pulling out their hair before they figure out the issue.

One issue:

User updates email address, email address is now set to not confirmed, user can not login now. User typed email in incorrectly, so can not confirm email or update email address.

  • Are we assuming that systems with this enabled will not be allowed to update their email.
  • Is this an UI issue for the developers and not a concern of this library.
@blowdart

This comment has been minimized.

Copy link
Member

blowdart commented Jan 31, 2019

We can't do that. Unless you expect us to scan a database on app startup every time. I suspect people would not like the increase in startup time. Instead it would only be turned on by default for new projects created within VS.

The update flow is also on the list of things to be fixed

@Ponant

This comment has been minimized.

Copy link
Contributor

Ponant commented Feb 12, 2019

Isn't it possible to just disconnect Email from Username, the latter being the only unique identifier of the user? This change would be done throughout the api and templates. Twitter style sounds good to me, the handler is the unique username and you can change it at will. Where would this be incompatible with the current Identity framework?

@Ponant

This comment has been minimized.

Copy link
Contributor

Ponant commented Feb 20, 2019

@HaoK do you mind explaining what is the problem? To me username and email are semantically different and thus should be kept separate. I currently have unique usernames (built in the api) and I require unique emails. But they are different from each others, and indeed users can change their emails but keep the same username. I just do not understand why you want to drop this kind of scenario?

@HaoK

This comment has been minimized.

Copy link
Member Author

HaoK commented Feb 20, 2019

@Ponant then you would not set this flag to true

@blowdart blowdart modified the milestones: 3.0.0-preview4, 3.0.0 Feb 28, 2019

@HaoK

This comment has been minimized.

Copy link
Member Author

HaoK commented Mar 9, 2019

We are tabling this for now, and just going to improve the flows, usernames different from emails will remain a scaffold/customization scenario with the default UI for now see #8356

@HaoK HaoK closed this Mar 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.