Fix #4752: validate the username and email.

[zyhfish]

No description provided.

[sbwalker]

@zyhfish can you please explain why there is a need for InstallUserManager? UserManager already pulls in UserManager<IdentityUser> through its constructor. I am also not understanding why you are calling var installUserManager = new InstallUserManager<IdentityUser>() - this is not using dependency injection and is a pattern we are trying to avoid in Oqtane.

[sbwalker]

@zyhfish on a side note I am wondering why so much of the code has been reformatted ie. 75% of the changes in this PR are not actually modifications at all, they are just reformatting. This makes the PR very difficult to review. It also makes the formatting of this class different than the rest of the Oqtane solution - which is not good for consistency (which is one of the Oqtane philosophies). Is the reformatting being caused by a third party development tool such as Resharper?

[zyhfish]

Hi @sbwalker ,
the introduce of InstallUserManager is because in the built-in user manager, it will try to validate exsiting user by username or email in the database, but actually we don't have any valid database yet before installation, so that it will throw out exception, so that I overwrite the methods to avoid the exception, this more work like a fake class and will only been used in the validation method, so it's not needed to register in DI.

the code formatting should be the different of "Tab" settings, it used 4 spaces instead of a real Tab char.

[sbwalker]

@zyhfish the validation logic in the .NET Identity library is rather basic (https://github.com/aspnet/Identity/blob/master/src/Core/UserValidator.cs) - basically Oqtane does not require unique email addresses, so the only thing this class is doing is validating the value conforms to the AllowedUserNameCharacters and then validating that the username is unique. So I believe that it may be better for Oqtane to have its own implementation for the ValidateUser method which does not rely on the .NET Identity classes at all. This would greatly simplify the code (ie. avoid the need for the mock class) and would provide more flexibility in the future for custom validations if necessary.

[sbwalker]

the majority of this PR was fine - I was just suggesting that the validation logic could be implemented in the UserManager without bothering to leverage the .NET Identity classes/methods. This would make the code simpler, reduce the number of dependencies, and provide more flexibility. Does this make sense?

[zyhfish]

Hi @sbwalker , the PR has been updated to use the simple chars validation.