Pregunta

Almaceno los datos del usuario en una tabla MSSQL llamada Usuarios. Lo que quiero es tener acceso a todos los datos del usuario para el usuario actualmente registrado (correo electrónico, dirección, teléfono, si el usuario está suscrito, etc.).

No quiero usar perfiles, así que decidí usar MembershipProvider personalizado (¿o conoces una forma mejor y menos dolorosa?).

Lo que no entiendo es MembershipUser y Membership. Si heredo de MembershipProvider, en los métodos anulados controlo los datos de acceso desde y hacia la base de datos.

¿Pero cómo uso la clase heredada de MembershipProvider? Si deseo autenticar a un usuario mediante membresía, debo hacer:

if(Membership.ValidateUser(string username, string password))
{
   FormsAuthentication.RedirectFromLoginPage(string username, string password);
}

Pero, ¿dónde se hereda la clase de MembershipProvider? ¿Y cuándo usar una clase heredada de MembershipUser? ¿Y cuál es la relación entre Membresía y MembresíaProveedor?

¿Fue útil?

Solución

Si bien no está claro como el cristal en MSDN , no es todo que complicado Hay un trío de clases:

  • Membresía: proporciona métodos de utilidad y un punto de entrada, básicamente un Singleton (clase estática).
  • MembershipProvider: actúa como accesor de datos y fábrica para los objetos MembershipUser.
  • MembershipUser: representa a un usuario individual.

Se selecciona un MembershipProvider personalizado (por código en Membership) en función de la configuración de su aplicación: configuration / system.web / Membership. Aquí es donde pone en juego a su proveedor. La implementación de MembershipProvider debe escribirse para acceder al almacén de datos que prefiera para los usuarios: su tabla de usuario en este caso.

Los objetos MembershipUser solo se crean a través de MembershipProvider. El método MembershipProvider.ValidateUser () debe verificar en su almacén de datos que la combinación de usuario / contraseña es válida. MembershipProvider.GetUser () recupera la información del usuario: úsela dentro de una página protegida de acceso y pase System.Web.HttpContext.Current.User.Identity.Name como el usuario autenticado actual.

Dicho esto, espero que esté seguro de que no quiere use Perfiles , y realmente quiero tener una tabla de usuario separada. Si está escribiendo una aplicación interna, utilizando un Active Directory existente o El almacenamiento de datos habilitado para LDAP reduciría los costos de administración y probablemente los riesgos de seguridad. Hay cientos de cosas que puedes hacer fácilmente mal al seguir la ruta de MembershipProvider. ¿Utiliza hash salados ? ¿Cómo protege la tabla de usuario contra la manipulación? MSDN cubre solo una fracción de los problemas de seguridad que puede enfrentar.

Otros consejos

El proveedor específico utilizado se controla en web.config. En realidad, puede configurar más de 1 proveedor y tener uno predeterminado. Comprobar: http://msdn.microsoft.com/en-us/library/ 6e9y4s5t.aspx .

Cuando se llama así, la membresía solo usa el proveedor predeterminado. Heredaría MembershipUser, si quisiera proporcionar información adicional para el usuario, pero eso vinculará el resto de su código a su proveedor específico.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top