asp.net - tutorial - membership asp net visual studio 2015
¿Por qué debería usar el modelo de seguridad de Membresía de ASP.NET? (9)
A menos que sea la única persona que trabajará en este sitio en particular, creo que el hecho de que sea familiar para los desarrolladores de .NET es una buena razón para utilizar la ruta integrada de Membresía. Otros desarrolladores con experiencia ASP.NET pueden saltar al proyecto y ponerse al día rápidamente en el modelo de autenticación / autorización de su sitio.
Usamos el modelo de proveedor de Membresía y Roles incorporado en nuestro sitio y funciona muy bien ... tuvimos que escribir nuestras propias clases de Proveedores, ya que usamos una base de datos de respaldo diferente para los datos (utilizamos Microsoft Dynamics CRM), pero estas clases son bastante simples y bien documentadas. Al hacer este pequeño trabajo desde el principio, ahora podemos usar las clases Membership y Roles en el código, así como los diversos controles del servidor relacionados con el inicio de sesión en nuestras páginas.
¿Hay alguna otra alternativa que estés considerando?
Estoy actualizando mi sitio web en este momento y supongo que si voy a actualizar mi modo de inicio de sesión / seguridad, ahora es un buen momento.
He revisado el modelo de membresía que se incluye en ASP.NET pero no estoy convencido de que proporcionará ningún beneficio además de ser familiar para otros desarrolladores de .NET.
Parece que hay bastante documentación para ello, pero poca discusión sobre por qué vale la pena el esfuerzo.
¿Alguien puede arrojar algo de luz sobre esto?
Está allí simplemente para que no tengas que hacer el tuyo.
Si alguna vez desea migrar su sitio a cualquier tipo de software de portal ya creado, como Community Server o DotNetNuke, el uso del proveedor de membresía permite una migración fácil. Incluso puede usar la base de datos existente y no tener que implementar nuevas.
Su valor es que es un marco de seguridad fácil de usar y basado en funciones. Si ya ha creado su propio marco de trabajo y la migración no es trivial, puede que no valga la pena. Pero uno de los beneficios de la migración sería que podría eliminar una gran cantidad de código de aplicación y reemplazarlo con código de marco.
Veo poco beneficio al usar membresía para un sitio grande. Esto se ha comercializado como "la" solución para la autenticación ASP.Net. Sin embargo, en realidad parece que Microsoft solo está tratando de posicionar el antiguo producto de Servidor de Membresía como algo que todo el mundo de repente necesita.
Trabajé en Membership Server en Msft hace unos 10 años. También fue un desarrollador líder en shop.microsoft.com, y puedo decirle que no usamos productos internos del servidor en ese sitio, no el servidor de comercio, ni el servidor de membresía. No estoy seguro de cómo lo están haciendo ahora, pero creo que el consenso general en ese punto fue que ese tipo de paquetes en general se interponía en el camino de lo que estábamos tratando de hacer.
Podría ser útil para un sitio más pequeño, o si tiene recursos limitados ... es decir, unos pocos cientos de usuarios para una intranet departamental o de una pequeña empresa, donde no desea invertir mucho tiempo o recursos. Cuanto más lo veo, más me parece completamente inapropiado para sitios web más grandes y personalizados.
Lo que realmente no entiendo es que casi todos los libros de ASP.Net parecen impulsar esto como la única forma de hacerlo, en lugar de una forma de hacerlo.
Escribí el mío después de leer todos los procedimientos almacenados en el proveedor de Membresía de ASP.NET. No es difícil y tienes mucho más control al final del día.
Si le gusta la configuración XML, cadenas de caracteres débilmente tipeados, inseguros por defecto, archivos web.config aleatorios esparcidos por sus directorios en lugar de una interfaz de marcador limpia en sus clases de página para decir ''no se requiere cuenta'', múltiples aciertos en la base de datos para un solo inicie sesión, los objetos de usuario que no están cargados desde su ObjectContext / DataContext actual y la capacidad de cambiar de proveedor sobre la marcha (¡vaya, ¿quién lo usa ?!) vaya para el incorporado.
Si no es así, compila el tuyo propio, pero si lo haces, asegúrate de almacenar un hash encriptado / salado de tus contraseñas, y haz una cookie cifrada apropiada, por favor.
[Actualizado para reflejar los comentarios en los comentarios]
Creo que una característica atractiva de la Membresía, Rol y Perfil de ASP.NET es que usa el modelo de proveedor. Si no está contento con él tal como está, no es difícil obtener el suyo propio de las clases base. Si observa codeplex.com, puede encontrar probablemente una docena o más de proveedores personalizados que las personas hayan escrito. Escribí uno para la base de datos SQLite hace unos años.
Lo único que realmente odio del MembershipProvider que viene con .Net es el hecho de que el ID de usuario es un GUID en lugar de una identidad autoincrementada. Sé que hay bonificaciones al uso de un GUID, pero integrarlo en sistemas o módulos preexistentes puede ser complicado.
La ruta de membresía funciona bien PERO hay un error fatal y no culpo a Microsoft por ello.
Internet Explorer es el único navegador que elimina correctamente la caché de autenticación.
Puedes cerrar un navegador Firefox, abrirlo y luego restaurar esa última sesión y volver directamente a tu sitio web "seguro" sin iniciar sesión. Chrome tiene problemas similares y cualquier cosa que Mac haga de la misma manera.
IE tiene una llamada javascript que maneja esto correctamente: document.execCommand ("ClearAuthenticationCache", "false");
No funciona con ningún otro navegador. Si usa esto, debe forzar a los usuarios a usar IE.