Práctica recomendada para mantener una identificación de usuario (MVC)

Question

Uso FormsAuthentication, pero he agregado un MemberShipProvider personalizado para validarlo en una tabla de usuario personalizada.

Todas las tablas que contienen "datos de usuario" tienen una columna idUser, por lo que debo mantener la identificación del usuario para presentar sus datos al usuario.

Anteriormente he utilizado una variable de sesión (ASP.NET Webform), pero como estoy reescribiendo la aplicación web a MVC, me gustaría preguntar qué se considera generalmente como el mejor enfoque para esto.

¿La variable de sesión sigue siendo el mejor lugar para guardar el idUser, o debería agregar un "Current.User.Identity" personalizado que además del nombre de usuario también tiene un userId público?

¿O debería elegir un enfoque completamente diferente?

Answer 1

Tuve la misma pregunta cuando implementé un proveedor de membresía personalizado para MVC. Terminé haciendo dos cosas. Guardo el ID del usuario en el campo ProviderUserKey del objeto MembershipUser. Ver provideruserkey. Luego, para responder a su pregunta, sí, creé un principal personalizado desde System.Web.Security.IPrincipal, aunque más tarde heredé de System.Web.Security.RolePrincipal en su lugar porque quería soporte para Roles.

public class MyPrincipal : RolePrincipal 
{ 
    public Guid Id { get; set; } 

    public MyPrincipal(string providerName, IIdentity identity, Guid id) : base(identity) 
    { 
     Id = id; 
    } 
} 

Actualización: La razón por la que no quiero usar la sesión en mi caso es así porque una vez inhabilitadas para la aplicación. He leído que el concepto central detrás de MVC es esa separación de preocupaciones, y eso modela de cerca la forma en que funciona la web, que es apátrida. Aunque no recuerdo dónde lo leí ahora que trato de recordar. Sin embargo, también recuerdo haber leído que si puedes eliminar la sesión deberías hacerlo. Permitirá que IIS envíe solicitudes simultáneas desde su aplicación en lugar de tener que esperar a que finalice una solicitud (y liberar la sesión del usuario) antes de que la siguiente solicitud pueda usar la sesión y enviar su respuesta. El mayor impacto de esto es cargar contenido de la página usando Ajax.

Answer 2

¿Son sus nombres de usuario únicos? De ser así, no es necesario mantener UserId, ya que puede recuperar un usuario por nombre de usuario.

Mis proyectos de MVC han implementado membresía de forma similar a la aplicación de formularios web tradicionales. No creo que haya ninguna razón para mirar los dos de manera diferente a menos que intente construir una aplicación de tipo REST sin estado. ¿Cómo mantienes tu ID de usuario en formularios web? ¿Sesión? Luego usa sesión en MVC. No hay razón para reinventar la rueda.

Por supuesto, si tiene otras razones para cambiar, hay muchas formas de almacenar el UserId. Puede almacenarlo en el UserData de la cookie de autenticación. También puede crear su propio ticket de autenticación que use UserId como clave en lugar del nombre de usuario. Incluso podría crear un Principal personalizado para almacenar información adicional.

Es posible que desee opinar Forms Authentication Configuration and Advanced Topics. Este artículo cubre el almacenamiento de datos adicionales (UserId) en el ticket de autenticación y la creación de un Custom Principal. Ambos métodos probablemente se ajusten a sus requisitos.