Proveedor De Membresía De Microsoft Vs Proveedor Personalizado Vs Sistema De Inicio De Sesión Personalizado Completo
Actualmente estoy convirtiendo un muy antiguo, pero que funciona sitio ASP clásico para ASP.Net.
Tiene un sistema de gestión de usuarios escrito completamente personalizado. Si bien funciona bien, realmente necesita una actualización, ya que quiero que sea más flexible para algunos proyectos futuros en las obras.
Cuando le pregunté a alguien sobre esto, me dijeron "Necesitas usar el proveedor de Microsoft" y di una conferencia sobre cómo Microsoft libera todas estas cosas de forma gratuita y lo buenas que son y deben volver a usarse tanto como sea posible.
He hecho un poco de investigación sobre él (principalmente mirando los videos en http://asp.net/learn ) y estoy muy impresionado por algunas de las características, ya que parece que hay componentes de arrastrar y soltar para los elementos que me llevaría años escribir.
Sin embargo, la base de datos de miembros actual es complicada de explicar, es una base de datos escrita completamente personalizada que tiene muchas relaciones internas... No es realmente "compatible" con el Microsoft predeterminado Proveedor.
He echado un vistazo a ¿Cómo puedo: Crear un Proveedor de Membresía Personalizado?, pero me siento un poco fuera de mi zona de confort y me preocupa que sea lento, introduzca un agujero de seguridad o simplemente no funcione.
Al final del día, el Proveedor de Membresía de Microsoft debería funcionar para mí-las únicas personalizaciones que realmente necesito es el inicio de sesión para usar el campo nombre de usuario / contraseña en mi base de datos y el script crear usuario que tiene una gran cantidad de código personalizado para varios terceros sistemas de partes (necesidad de prestar servicios, etc.).
Me preguntaba, ¿qué harías si te enfrentaras a una situación similar?
-
Use el Proveedor de membresía de Microsoft y de alguna manera haga que funcione para usted (aunque me gustaría recibir sugerencias)
Use el proveedor de membresía de Microsoft, pero use un proveedor personalizado que se personalice en torno a su código.
Utilice su propia solución completamente personalizada?
4 answers
Ese video complica las cosas :) Si vas a implementar un proveedor personalizado, entonces reflector sobre el existente es un buen lugar para comenzar:)
Como una opción rápida y sucia, por supuesto, podría hackear los procedimientos almacenados que utiliza el proveedor de membresía SQL, pero el código personalizado para aprovisionar servicios probablemente lo esté estirando.
Si lo piensas bien, el aprovisionamiento remoto de servicios no pertenece realmente a un proveedor de membresía, no es realmente una membresía función - todo lo que hace la membresía es proporcionar nombres de usuario y contraseñas y autenticación alrededor de ellos. Mi propia sensación es que usted debe mover el suministro de servicios fuera de allí, y realizarlo en el ASP.NET sitio después de que se ha creado un usuario, incluso si eso es solo llamar a un procedimiento almacenado una vez que el proveedor de membresía ha hecho su trabajo. Si hace esto, puede encontrar que el proveedor de membresía SQL hará todo lo que necesite (probablemente con los proveedores de roles y perfiles también), y por lo tanto ¡tienes mucho menos código para escribir!
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-12-04 11:07:52
He estado en situaciones similares en el pasado. En ambos casos creamos implementaciones personalizadas de los proveedores (MembershipProvider, RoleProvider, ProfileProvider) alrededor del mecanismo existente.
En ambos casos solo usamos las implementaciones del proveedor para el acceso de solo lectura, por ejemplo, para darnos los gubbins de validación fácil en la web.config y cosas así. El código de administración del usuario se dejó bien solo, ya que funcionó bien.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-12-04 10:53:01
Si el proveedor existente funciona (tiene los campos correctos para sus datos), use eso para comenzar. Puede reemplazarlo fácilmente con un proveedor de clientes más tarde (solo un cambio de valor de configuración).
Cuidado no hay un "fuera de la caja" ASP.NET interfaz de administración para eso, tendrá que rodar su propio o utilizar uno de terceros.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-12-02 18:32:44
Use mi membershiprovider especializado para trabajar contra mis propias tablas de base de datos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-12-04 11:10:59