¿Cuáles son las desventajas de usar / escribir un proveedor de membresía personalizada .Net?

Recientemente, publiqué la siguiente pregunta en SO: /programming/7197337/using-asp-net-membership-provider-with-an-existing-user-database

Como puede observar, terminé respondiendo mi propia pregunta afirmando que parecía que escribir / implementar un "Proveedor de membresía personalizado" era el camino a seguir.

Literalmente, unos minutos después, me encuentro con esta pregunta: /programming/7222306/simple-login-attempt-counter-using-mvc-3-and-ajax/7222407#7222407

Intento responder y recibir un comentario de que el proveedor de membresía .Net es "terrible en muchos niveles". Lo admito, esta es la primera vez que uso el proveedor de Membresía, pero seguro que me pareció elegante.

No he visto nada que respalde la afirmación "terrible", así que antes de implementar algo "terrible", esperaba recibir algunos comentarios de la comunidad.

Así que no estoy seguro de que "terrible" sea la mejor palabra aquí. Sin embargo, tiene limitaciones, y tan pronto como sus necesidades no se ajusten a la forma en que se diseñó el proveedor de membresía, terminará con mucho código de pegamento. Si puede usar el proveedor de membresía de inmediato, yo diría que lo haga. Tan pronto como comience a escribir uno personalizado, cuestiono el uso de la membresía de todos modos.

En mi experiencia, el proveedor de membresía te compra ...

• Regístrese ya integrado en la aplicación MVC
• Edición de cuenta
• Olvidé mi contraseña es fácil de conectar
• Validar método de usuario

Estoy seguro de que me falta algo más, pero creo que esos son los más importantes. Ahora, cuando necesita una administración de contraseñas personalizada, autenticación de dos factores, para trabajar con un modelo de datos existente o una gran cantidad de otras cosas, comienza a perder. El código que ya está escrito para usted con la membresía debe tardar unos días en duplicarse si sabe lo que está haciendo.

No hace lo que quieres. A primera vista, puede encontrar que se ocupa de todas sus necesidades y algunas, pero surge un nuevo requisito. Ahora 'realmente' tienes que aprender cómo funciona esto. El beneficio de tener todo esto preconstruido disminuye porque estabas en esa falsa sensación de seguridad.

@Travis mencionó el uso de un modelo de datos existente, pero la elección de la base de datos también puede ser una restricción: ¿Oracle?

No sé si funciona con sistemas de verificación de terceros como Facebook o Google.

No son tan flexibles como mucha gente piensa en una lectura rápida de los documentos, pero tienen su lugar.

Si no necesita control sobre los tokens de usuario y solo necesita crear un conjunto de datos de usuario o de membresía personalizado / extendido o necesita extraer esos datos de una fuente existente / diferente que tienen su lugar.

Si desea modificar más que eso, a menudo es mejor reemplazar el httpmodule que ejecuta uno de los proveedores de autenticación, entonces obtendrá todo el control. La mayoría de las personas con las que me he encontrado rompiendo cosas con los proveedores tomaron la decisión equivocada para su situación a este nivel.

De cualquier manera, obtienes un context.user correctamente poblado que te permite continuar usando la mayoría de las funciones de usuario basadas en asp.net.

Esta pregunta es antigua, pero recibo insignias por su popularidad, así que creo que vale la pena proporcionar una respuesta actualizada.

El proveedor de membresía "Simple" de Microsoft finalmente lo hizo bien en mi humilde opinión. Si está escribiendo algo nuevo o incluso adjuntando a una base de datos heredada con una nueva aplicación. Use el proveedor de membresía simple. MANERA MÁS FÁCIL y LIMPIA para implementar. Instale un par de tablas y señale al proveedor a su lista de usuarios y ya está listo.

Este enlace lo ayudará a comenzar o simplemente búsquelo en Google: http://www.mattjcowan.com/funcoding/2012/11/10/simplemembershipprovider-in-mvc4-for-mysql-oracle-and-more-with-llblgen/