none
sus recomendaciones en Login MVC RRS feed

  • Pregunta

  • Hola, estoy haciendo un proyecto para la universidad en MVC 4, la aplicación ya realiza lo que se nos ha pedido excepto por una observación que nos hicieron este día en que para gestionar los usuarios no utilicemos ni de broma membership, entonces quiero consultarles que opinan de mi solución a la gestión de usuarios:

    Creare dos tablas en SQL Server las cuales estarán relacionadas, una de roles(PK: IDRol) y otra con los usuarios(PK: IDUsuario – FK: IDRol).

    Creare una Vista para Login y desde la carpeta Model me creare una clase que se conecte con la BD y verifique los datos del usuario(username y password), en caso de ser correctos me traigo el rol que le corresponde al usuario y lo mando al controlador controlcontroller(por ej) y en este controlador utilizo FormsAuthentication.SetAuthCookie("usuario", true);

    Y en cada controller utilizo authorize en cada accion del controlador que necesito autorizacion.

    Como les dije quisera pedirles su opinion a mi solucion por favor, cualquier observacion y/o recomendación es bienvenida y muy bien agradecida.

    Tambien pedirles ayuda en como mandar la informacion(usuario y rol) desde el modelo al controlador.

    pabletoreto

    sábado, 29 de noviembre de 2014 20:49

Respuestas

  • Bueno...

    Yo creo que hay muchas razones para no usar el membership clásico en MVC. Para empezar solo te hace el trabajo si te adhieres a su esquema de datos. Si quieres usar otro esquema de datos debes implementar un custom provider lo que no te ahorra trabajo para nada... y además debes implementar (o dejar con un NotImplementedException) muchos métodos que probablemente no necesitas (vas a banear users en tu site?)

    El problema de Membership es que está orientado a webforms, donde hay una serie de webcontrols que sí que lo usan y que le sacan partido. Entonces usar el combo membership+webcontrols de webforms es una buena idea, y te permite implementar un sistema de login y control de usuarios de forma rápida y sencilla. Pero en MVC no tenemos esos controles, así que no veo porque se debe pagar el precio de usar Membership.

    SimpleMembership modifica un poco la discusión solo sea por permitir usar oAuth en mi site, que es algo que es bastante interesante.

    Y por supuesto Identity es otra cosa totalmente distinta... No hay motivo para no usar Identity (y más 2.0 que ya tiene soporte para escenarios avanzados como two factor).

    @pabletoreto Lo que haces no me parece mal... en efecto estás haciendo lo mismo que hace Membership, pero es que Membership en MVC es poco más que un DAO y que encima te obliga a adherirte a un esquema de datos concreto.


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    • Marcado como respuesta pabletoreto martes, 2 de diciembre de 2014 14:04
    lunes, 1 de diciembre de 2014 10:26

Todas las respuestas

  •  >>Tambien pedirles ayuda en como mandar la informacion(usuario y rol) desde el modelo al controlador.

    podrias agregar datos adicionales al ticket de autenticacion

    Add Custom Data to the Authentication Method 


    para despues creando un custom bindiang poder inyectar en el parametro del action el usuario o rol

     ASP.NET MVC Custom Model Binding

    en tu caso crearias un model binder que tome la info del ticket y la devuelva para inyectarla en el action con la info del usuario

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    domingo, 30 de noviembre de 2014 5:59
  • [...] no utilicemos ni de broma membership [...] quisera pedirles su opinion a mi solucion [...]

    Habría que ver cuáles son los motivos por los que te han dicho que no utilices ni de broma Membership, porque resulta que Membership hace exatamente lo mismo que has propuesto en tu solución (estoy hablando del Membership tradicional, no del SimpleMembership que se instala de forma predeterminada con la versión 4, aunque éste también valdría). Es decir, Membership crea una tabla de roles y otra de usuarios, y las relaciona por el IdRol igual que tú propones. La plantilla de Visual Studio para login hace lo mismo que tú propones, es decir, crea una vista para Login y en Model crea una clase que conecta con la BD, verifica el username y el password (lo mismo que tú propones). Y en caso de ser correctos, establece la cookie de autenticación igual que tú propones. Después, en el controlador, se autoriza cada acción por medio del filtro [Authorize], que probablemente era lo que tú tenías en mente.

    Así que no tiene mucho sentido que "reinventes la rueda". Si ya existe un conjunto de herramientas que hace exactamente lo mismo que quieres hacer (Membership), ¿por qué no usarla?

    domingo, 30 de noviembre de 2014 8:29
  • Bueno...

    Yo creo que hay muchas razones para no usar el membership clásico en MVC. Para empezar solo te hace el trabajo si te adhieres a su esquema de datos. Si quieres usar otro esquema de datos debes implementar un custom provider lo que no te ahorra trabajo para nada... y además debes implementar (o dejar con un NotImplementedException) muchos métodos que probablemente no necesitas (vas a banear users en tu site?)

    El problema de Membership es que está orientado a webforms, donde hay una serie de webcontrols que sí que lo usan y que le sacan partido. Entonces usar el combo membership+webcontrols de webforms es una buena idea, y te permite implementar un sistema de login y control de usuarios de forma rápida y sencilla. Pero en MVC no tenemos esos controles, así que no veo porque se debe pagar el precio de usar Membership.

    SimpleMembership modifica un poco la discusión solo sea por permitir usar oAuth en mi site, que es algo que es bastante interesante.

    Y por supuesto Identity es otra cosa totalmente distinta... No hay motivo para no usar Identity (y más 2.0 que ya tiene soporte para escenarios avanzados como two factor).

    @pabletoreto Lo que haces no me parece mal... en efecto estás haciendo lo mismo que hace Membership, pero es que Membership en MVC es poco más que un DAO y que encima te obliga a adherirte a un esquema de datos concreto.


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    • Marcado como respuesta pabletoreto martes, 2 de diciembre de 2014 14:04
    lunes, 1 de diciembre de 2014 10:26
  • Hola, yo estoy de acuerdo con lo que dijeron ustedes. Pero para darle una vueltita más al modelo, no soporta que un usuario tenga más de un Rol. A mi siempre me ha venido bien que un usuario pueda tener más de un rol, no se si es el caso para los requisitos de pablotoreto. Para eso habría que implementar una tabla que relacione Roles y Usuarios en una relación N a M.

    Salu2

    lunes, 1 de diciembre de 2014 10:43
  • [...] no soporta que un usuario tenga más de un Rol [...]


    ¿Con Membership? Sí que soporta más de un rol. Tiene una tabla de usuarios-roles para hacer la relación de muchos a muchos.
    lunes, 1 de diciembre de 2014 12:09
  • Membership tiene una relación de n:m entre usuarios y roles. No hay problema en eso.

    Mis argumentos en contra de membership no son en cuanto a la funcionalidad que ofrece, es en que, para MVC, no le termino de ver sentido, a no ser que te esté bien adoptar su modelo de datos (entonces nada que objetar). Y hablo del membership clásico. Pero funcionalmente ofrece todo lo que cualquier site "normal" necesita (si requieres temas avanzados como doble factor de autenticación entonces membership no te ayuda).

    Saludos!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis


    lunes, 1 de diciembre de 2014 13:05
  • Bueno...

    Yo creo que hay muchas razones para no usar el membership clásico en MVC. Para empezar solo te hace el trabajo si te adhieres a su esquema de datos. Si quieres usar otro esquema de datos debes implementar un custom provider lo que no te ahorra trabajo para nada... y además debes implementar (o dejar con un NotImplementedException) muchos métodos que probablemente no necesitas (vas a banear users en tu site?)

    El problema de Membership es que está orientado a webforms, donde hay una serie de webcontrols que sí que lo usan y que le sacan partido. Entonces usar el combo membership+webcontrols de webforms es una buena idea, y te permite implementar un sistema de login y control de usuarios de forma rápida y sencilla. Pero en MVC no tenemos esos controles, así que no veo porque se debe pagar el precio de usar Membership.

    SimpleMembership modifica un poco la discusión solo sea por permitir usar oAuth en mi site, que es algo que es bastante interesante.

    Y por supuesto Identity es otra cosa totalmente distinta... No hay motivo para no usar Identity (y más 2.0 que ya tiene soporte para escenarios avanzados como two factor).

    @pabletoreto Lo que haces no me parece mal... en efecto estás haciendo lo mismo que hace Membership, pero es que Membership en MVC es poco más que un DAO y que encima te obliga a adherirte a un esquema de datos concreto.


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    Que interesante tu aclaracion, me sirvió de guía para buscar en internet y tienes mucha razón, ahora, tendrás link de Identity, eso nunca lo había ni siquiera escuchado

    pabletoreto

    lunes, 1 de diciembre de 2014 15:59
  • Buenas

    http://asp.net/identity

    Pero identity es para MVC5.

    Saludos!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis


    martes, 2 de diciembre de 2014 10:20