tutorial tables net mvc español asp asp.net asp.net-identity

tables - asp.net identity tutorial español



Configure Microsoft.AspNet.Identity para permitir la dirección de correo electrónico como nombre de usuario (8)

Estoy en el proceso de crear una nueva aplicación y comencé a usar EF6-rc1, Microsoft.AspNet.Identity.Core 1.0.0-rc1, Microsoft.AspNet.Identity.EntityFramework 1.0.0-rc1, Microsoft.AspNet.Identity .Owin 1.0.0-rc1, etc. y con los lanzamientos de RTM ayer, los actualicé a través de NuGet esta tarde a RTM.

Además de un par de cambios de código en el trabajo que había hecho hasta ahora, todo parecía ir bien, hasta que intenté crear una cuenta de usuario local para la aplicación.

He estado trabajando en direcciones de correo electrónico como el formato de nombre de usuario, que con el candidato de lanzamiento funcionó muy bien, pero ahora cuando se crea un usuario con una dirección de correo electrónico para un nombre de usuario, se produce el siguiente error de validación:

User name [email protected] is invalid, can only contain letters or digits.

Pasé la última hora buscando una solución o documentación sobre las opciones de configuración, pero fue en vano.

¿Hay alguna manera de configurarlo para permitir direcciones de correo electrónico para nombres de usuario?



En mi caso, ejecutándose en VS 2013 C #, MVC 5.2.2, usando ASP.NET Identity 2.0, la solución fue actualizar el constructor ApplicationUserManager dentro de App_Start / IdentityConfig.cs de la siguiente manera:

public ApplicationUserManager(IUserStore<ApplicationUser> store) : base(store) { this.UserValidator = new UserValidator<ApplicationUser>(this) { AllowOnlyAlphanumericUserNames = false }; }


En mi caso, tenía una clase de repositorio trabajando con autenticación, que no me permitía usar un "-" dentro de los nombres de usuario ... La solución estaba dentro del constructor aquí:

//------------------------------------------------------- public AuthRepository() //------------------------------------------------------- { _ctx = new AuthContext(); _userManager = new UserManager<IdentityUser>(new UserStore<IdentityUser>(_ctx)); _userManager.UserValidator = new UserValidator<IdentityUser>(_userManager) { AllowOnlyAlphanumericUserNames = false }; }


La versión C # de esto (en App_Code / IdentityModels.cs) es

public UserManager() : base(new UserStore<ApplicationUser>(new ApplicationDbContext())) { UserValidator = new UserValidator<ApplicationUser>(this) { AllowOnlyAlphanumericUserNames = false }; }


Puede permitir esto al conectar su propio UserValidator en el UserManager, o simplemente al desactivarlo en la implementación predeterminada:

UserManager.UserValidator = new UserValidator<TUser>(UserManager) { AllowOnlyAlphanumericUserNames = false }


Si está utilizando formularios web ASP.Net y está intentando lograr esto, simplemente abra su archivo IdentityModels.vb / cs y en Public Class UserManager, haga que se vea así:

Public Class UserManager Inherits UserManager(Of ApplicationUser) Public Sub New() MyBase.New(New UserStore(Of ApplicationUser)(New ApplicationDbContext())) Users = store UserValidator = New UserValidator(Of ApplicationUser)(Me) With {.AllowOnlyAlphanumericUserNames = False} End Sub Public Property Users() As IUserStore(Of ApplicationUser) Get Return m_Users End Get Private Set(value As IUserStore(Of ApplicationUser)) m_Users = value End Set End Property Private m_Users As IUserStore(Of ApplicationUser) End Class


Si no puede encontrar IdentityConfig.cs, reemplace su constructor AccountController con este código.

public AccountController(UserManager<ApplicationUser> userManager) { UserManager = userManager; UserManager.UserValidator = new UserValidator<ApplicationUser>(UserManager) { AllowOnlyAlphanumericUserNames = false }; }


También estuve atascado con esto porque la mayoría de las veces los nombres de usuario son correos electrónicos en estos días, aunque puedo entender el razonamiento de un campo de correo electrónico separado. Estos son puramente mis pensamientos / experiencias, ya que tampoco pude encontrar la opinión de Microsoft sobre esto.

Recuerde, Asp Identity es solo para identificar a alguien, no es necesario que tenga un correo electrónico para identificar, pero nos permite almacenarlo porque forma parte de una identidad. Cuando crea un nuevo proyecto web en Visual Studio, tiene la opción de opciones de autenticación.

Si selecciona un tipo de proyecto no vacío como MVC y establece la autenticación en "Cuentas individuales", entonces se le proporcionan los fundamentos básicos para la administración del usuario. Uno de los cuales incluye una subclase que se ve así en App_Start / IdentityConfig.cs:

// Configure the application user manager used in this application. UserManager is defined in ASP.NET Identity and is used by the application. public class ApplicationUserManager : UserManager<ApplicationUser> { public ApplicationUserManager(IUserStore<ApplicationUser> store) : base(store) { } public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, IOwinContext context) { var manager = new ApplicationUserManager(new UserStore<ApplicationUser>(context.Get<ApplicationDbContext>())); // Configure validation logic for usernames manager.UserValidator = new UserValidator<ApplicationUser>(manager) { AllowOnlyAlphanumericUserNames = false, RequireUniqueEmail = true }; } //N.B rest of code removed }

Lo que esto nos dice es que Microsoft tiene la intención de que almacenemos nombres de usuario más complejos (consulte AllowOnlyAlphaNumericUserNames = false), así que realmente tenemos señales mixtas.

El hecho de que esto se genere a partir de un proyecto web predeterminado nos da una buena indicación / dirección de parte de Microsoft (y una forma clara) de permitirnos ingresar correos electrónicos para el campo de nombre de usuario. Está limpio porque el método de creación estático se usa dentro de App_Start / Startup.Auth.cs cuando se inicia la aplicación con el contexto de Microsoft.OWIN.

El único inconveniente de este enfoque es que terminas almacenando el correo electrónico dos veces ... ¡lo cual no es bueno!