Autenticación ASP.NET MVC utilizando una base de datos personalizada en lugar de ASPNETDB?

Question

Ya tengo una tabla User en la base de datos de mi aplicación principal con una dirección de correo electrónico (que actuará como nombre de usuario) y una contraseña. Me gustaría autenticar el uso de mi base de datos en lugar de la base de datos de autenticación predeterminada (ASPNETDB).

Preguntas:

1. ¿Es esta una mala idea? ¿Es una gran lata de gusanos utilizar mi propia base de datos para la autenticación?

2. ¿Cuánto trabajo agrego al hacer esto? Ya tengo un código para hash la contraseña y una consulta que verificará si el correo electrónico y la contraseña coinciden con la base de datos. Entonces, no comenzaría de cero.

3. ¿Qué tendría que hacer para usar mi base de datos en lugar de ASPNETDB? Espero que esto pueda describirse en unos pocos pasos simples, pero si no, ¿podría señalarme una buena fuente?

actualización

Todavía estoy en busca de un poco más de detalle aquí en mi tercera pregunta. ¿Debo escribir mi propio MembershipProvider? ¿Qué cambios debo hacer en mi archivo web.config? ¿Funcionará el atributo [Authorize] si escribo mi propia solución? ¿Puedo usar AccountController generado automáticamente con algunas modificaciones menores o básicamente necesito reescribir el controlador de cuenta desde cero?

Answer 1

Es bastante simple, debe derivar MembershipProvider e implementar el método ValidateUser. Eche un vistazo a este post. Estoy usando un proveedor de membresía personalizado con Postgres y MVC.

Answer 2

1. No. Y sospecharían mayoría de la gente no confía en que el mecanismo sucia

2. No mucho, sobre todo porque usted tiene la tabla ya.

3. Tome un vistazo a esto, por ejemplo: http://forums.asp.net/t/1250726.aspx

Answer 3

Estamos haciendo exactamente esto en una de nuestras aplicaciones, y les resulta bastante sencillo. Tenemos un servicio de autenticación (llamado desde el controlador) que maneja los mecanismos de hashing de la contraseña ingresada para ver si es una coincidencia, luego simplemente devuelve un bool para un método que llamamos "IsValidLogon".

En nuestro caso, el objetivo era mantener la gestión de lo que debería ser una tarea bastante trivial lo más liviana posible.

Básicamente ignoramos ASPNETDB por completo. Si obtenemos una respuesta válida de nuestra verificación de usuario/contraseña, simplemente llamamos al estándar FormsAuthentication.RedirectFromLoginPage (username, createCookieBool);

Espero que ayude.

Answer 4

sólo la construcción de la misma, por lo que responder a 1 no debe ser :) estoy usando el estándar de autenticación de formularios de ASP.NET, donde utilizo el método FormsAuthentication.RedirectFromLoginPage (nombre de usuario, createCookieBool) para registrar un usuario en. Le di a un usuario un guid único (puede usar cualquier otro ID de usuario) y lo estoy almacenando en el parámetro UserName junto con el nombre de usuario (para mostrar en la página maestra: Html.Encode (Page.User.Identity.Name). Split ("|".ToCharArray()) [1]))

En cada controlador/método en el que debo saber qué usuario está conectado (a través de User.Identity.Name, divida la cadena y obtenga el userguid). También decorar esas rutinas con el atributo [Autorizar].

Answer 5

voy a responder a sus preguntas actualizados:

¿Tengo que escribir mi propia MembershipProvider?

Si (a) desea continuar utilizando la Autenticación de formularios, y (b) tiene una estructura de tabla de autorización que no sigue las mismas convenciones que ASPNETDB, entonces sí. Si no necesita FormsAuth (ver a continuación), puede eliminar completamente el MembershipProvider, pero yo no lo recomendaría. O bien, si está utilizando exactamente las mismas tablas de seguridad que ASPNETDB, pero solo desea apuntarlo a una base de datos diferente, puede continuar utilizando el proveedor predeterminado y simplemente cambiar su configuración.

¿Qué cambios debo hacer en mi archivo web.config?

Si está utilizando su propio encargo MembershipProvider, entonces usted necesita para registrarlo en la sección <providers> del elemento <membership> y cambie la propiedad defaultProvider. Si está utilizando el estándar AspNetSqlProvider, entonces probablemente solo necesite cambiar la cadena de conexión.

¿El atributo [Autorizar] seguirá funcionando si escribo mi propia solución?

Sí, si se apega a la Autenticación de formularios (use AspNetSqlProvider o escriba y registre su propio proveedor de membresía). No, si abandona la Autenticación de formularios (de nuevo, no recomendado).

¿Puedo usar el AccountController generado automáticamente con algunas modificaciones menores o básicamente necesito reescribir el controlador de cuenta desde cero?

Debe volver a escribir el AccountController de todas formas; no deje el código de demostración en una aplicación de producción. Pero si debe hacerlo, sí, el AccountController funcionará en las mismas condiciones que arriba.

Answer 6

Hola, Sólo tienes que seguir estos sencillos pasos:

Primera, puede eliminar el archivo .mdf en la carpeta App_Data. Ya que no necesitamos ninguna de estas tablas. Luego,, necesitamos actualizar la cadena de conexión predeterminada en el archivo web.config para que apunte a nuestra base de datos.

<connectionStrings> 
    <add name=”DefaultConnection” connectionString=”Data Source=SERVER\INSTANCENAME;Initial Catalog=DBNAME;Integrated Security=True” providerName=”System.Data.SqlClient” /> 
    </connectionStrings> 

Tercer, Open Nuget Gestor de paquetes y escribir los siguientes comandos:

Enable-Migrations 
Add-Migration Init 
Update-Database 

comprobar si en su base de datos, todas las tablas de miembros ASP.NET con prefijo Asp han sido crear y entonces se puede probar ejecutar su aplicación y ejecutar acciones de membresía como Registrarse o Iniciar sesión en su aplicación.

crean las tablas después de ejecutar los comandos anteriores:

• AspNetRoles
• AspNetUserClaims
• AspNetUserLogins
• AspNetUserRoles
• AspNetUsers
• __MigrationHistory

Fuente: https://blogs.msmvps.com/marafa/2014/06/13/how-to-create-asp-net-mvc-authentication-tables-in-an-existing-database/