tutorial - ¿No es una mala idea usar el proveedor de membresía asp.net?
membership asp net visual studio 2015 (9)
¿Es generalmente una mala idea no usar el proveedor de membresía asp.net incorporado?
Siempre he puesto en marcha mi propia aplicación para mis aplicaciones asp.net (cara al público), y realmente no he tenido ningún problema al hacerlo. Funciona, y parece evitar una capa de complejidad. Mis necesidades son bastante básicas: una vez configurado, el usuario debe usar la dirección de correo electrónico y la contraseña para iniciar sesión, si lo olvidan, se las enviaremos por correo electrónico (una nueva). Después de la configuración, es poco lo que se necesita hacer con cada cuenta de usuario, pero sí necesito almacenar varios campos adicionales con cada usuario (nombre completo, teléfono y algunos otros campos, etc.). La cantidad de usuarios que requieren credenciales de inicio de sesión es pequeña (generalmente solo el administrador y algunas copias de seguridad), y todos los demás usan el sitio sin autenticar.
¿Cuáles son las grandes ventajas que podría estar perdiendo al saltarme la funcionalidad del proveedor de membresía de asp.net?
¿Cómo se guardan las contraseñas de los usuarios? Si está guardando en texto plano, es un gran riesgo. Una de las ventajas del sistema de membresía de ASP.NET es que encripta las contraseñas mediante hash, fuera de la caja.
En su caso, los usuarios autenticados son la excepción, no la norma, por lo que probablemente no le haga daño rodar los suyos.
Una cosa que proporciona .net es una prevención de ataques de fuerza bruta, en caso de que alguien intente forzar la contraseña de administrador, la cuenta de administrador se bloqueará.
Estoy de acuerdo con los sentimientos de Ayende sobre esto :
Es una API enorme, hace muchas suposiciones y realmente no es agradable trabajar en términos de lo que te da y lo que tienes que implementar.
Esta es también mi experiencia. Cada vez que implementé mi propio proveedor de membresía (dos veces en el momento de escribir este artículo) dejé la mayoría de los métodos anulados sin implementar, porque nunca los iba a llamar y no estaba usando ninguno de los formularios web Controles que hacen uso de ellos.
Los proveedores de Sql y Active Directory son excelentes si satisfacen todas sus necesidades. Pero si no lo hacen y usted está pensando en implementar los proveedores, puede haber una mejor manera para usted.
No confunda el MembershipProvider con FormsAuthentication , en el que aún confío regularmente para mis aplicaciones. Este es el mecanismo que se ocupa de envolver el token de autenticación del usuario en una cookie y de pasar entre el cliente y el servidor. No hay nada malo con FormsAuthentication por lo que sé y no sugeriría reinventarlo.
Si no desea implementar docenas de métodos MembershipProvider , RoleProviderMethods y RoleProviderMethods , simplemente implemente IPrincipal y IIdentity y haga lo que tenga que hacer. Aquí hay un ejemplo de cómo hacer que esas 2 interfaces funcionen con FormsAuthentication, lo cual es trivial.
Además, tenga en cuenta que debe ser inteligente al almacenar las credenciales de sus usuarios. El proveedor de SqlMembershipProvider puede al menos almacenar contraseñas con sal. Asegúrate de al menos hacer lo mismo. Aquí hay una buena pieza de código para ayudar con esto. Observe el algoritmo de hashing lento utilizado . No hagas drogas.
actualización (2013-12-16)
Las cosas han cambiado en ASP.net desde que escribí esto. La identidad de ASP.NET reemplaza las características de membresía de antes.
Mi recomendación es usar las cosas nuevas porque:
- Puede implementar varias interfaces para componer una solución que satisfaga sus necesidades. Esto significa que puede implementar las partes que desee e ignorar las partes que no.
- Puede cambiar por completo dónde y cómo almacena los datos de identidad, al mismo tiempo que conserva la implementación predeterminada que controla la forma de las contraseñas.
- Características de OAuth y OpenID.
- Puede usar el mismo sistema en cualquier marco construido en OWIN.
La API es un poco más complicada que antes, pero más flexible.
Hay más en la membresía que solo membresía (inicio de sesión, correo electrónico, contraseña y funcionalidad). Aspnet separa la membresía del perfil, y pueden integrarse. Perfil es todo lo que llamas "campos extra". Puede tener un perfil anónimo con cierta personalización, incluso si no tiene una membresía. Por ejemplo, un usuario puede configurar las preferencias, volver al sitio y aún tenerlas, pero no registrarse. Luego, cuando se registra, se puede migrar un perfil anónimo y asociarlo con su nueva membresía.
Eso es lo que básicamente extrañas cuando lo omites.
Además, si elige utilizar controles integrados o de terceros que hagan uso de la membresía y los perfiles, también lo perderá.
Podría implementar un proveedor, en lugar de descartar el modelo de proveedor a la vez.
Las ventajas del modelo de proveedor se describen aquí , pero en breve:
Ciertos controles web listos para usar están diseñados para usar el modelo de proveedor de membresía, como el control / vista de inicio de sesión y el Asistente para crear usuarios. Por lo tanto, se pierde una configuración de 1 paso por tener un panel de inicio de sesión para todas sus páginas sin escribir ningún código.
Los proveedores pueden intercambiarse con un simple cambio en el archivo web.config. No digo que no pueda escribir sus propios datos de inicio de sesión para hacer lo mismo, pero puede escribir fácilmente un proveedor personalizado en algún momento y cambiarlo a su aplicación sin cambiar nada en la aplicación.
Se proporcionan todos los conceptos básicos. Los proveedores de membresía predeterminados tienen recuperación de contraseña, bloqueo de cuenta, métodos de cifrado de contraseña múltiple, configuración de regla de restricción de contraseña válida y administración de usuarios, todo listo para usar. El solo uso de eso es una gran reducción en el tiempo de configuración para la mayoría de las personas que inician una aplicación ASP.Net desde cero.
Un gran componente de su aplicación ya está vetado. ¡No necesita preocuparse por depurar todo su propio código de autenticación! Esto significa que cuando hay errores, a menudo obtienes correcciones antes de los descansos del sitio, y tienes la capacidad de pasar la culpa si no es así.
Poner en marcha su propio sistema de autenticación nunca es una buena idea. Hay tantas formas de equivocarse que aún parecen funcionar en las pruebas, hasta un año más tarde, cuando se entera de que su sitio fue dañado hace seis meses.
Siempre inclínese lo más posible en el código de seguridad proporcionado por su plataforma, ya sea asp.net o cualquier otra cosa. Haga esto, y el sistema es compatible con un proveedor con muchas más implementaciones para que los errores se puedan encontrar y corregir más fácilmente, e incluso si tiene un problema, puede culpar al proveedor cuando su jefe se lo pregunte. Sin mencionar que una vez que haya pasado la primera vez que usa la solución de su proveedor, las implementaciones adicionales serán más rápidas. Esta es la manera correcta de hacerlo.
El proveedor de membresía de ASP.Net está lejos de ser perfecto, pero le prometo que es preferible construirlo desde cero.
Puede obtener alguna información de estas otras preguntas populares:
¿Qué esquemas de autenticación y autorización está utilizando y por qué?
Si tienes una solución que funciona bien , quédate con ella. "Si algo funciona, no lo arregles" y todo eso. De lo contrario, considere que la API de membresía tiene miles de veces más que el número de horas de programación, QA y horas de usuario que cualquier otra cosa que pueda obtener por su cuenta.
Siento tu dolor con las complejidades de la autenticación ASP.Net incorporada. Estaba cansado de tener que escribir código para características que nunca iba a usar. (Además de dejar un montón de funciones NotImplemented). También estaba harto de las dificultades de usar algo que no sea un GUID y tener múltiples viajes de base de datos en cada carga de página (solo para autenticación) ... Entonces, hice mi propia cuenta. Se llama FSCAuth y tiene licencia BSD.
Lo he hecho un poco más difícil que la autenticación incorporada de ASP.Net para equivocarme también. Todo el manejo de cookies y el hash real se deja en el núcleo de FSCAuth, mientras que todo lo que tiene que preocuparse es almacenar a los usuarios en la base de datos y controlar en qué páginas deben autenticarse.
Si se enfrenta a la cuestión de la autenticación incorporada de ASP.Net y su propia versión, le sugiero que primero eche un vistazo a mi biblioteca de autenticación, si no solo que la utilice como punto de partida.