En circunstancias normales, cuando gestionamos los derechos de acceso, guardamos la información básica del usuario tras el inicio de sesión correcto y la obtendremos cada vez que el usuario solicite datos de página o interfaz en el futuro
Sesión para ver y comparar si está conectado y si puede acceder a la página actual.
El principio de Session es generar un SessionID en el lado del servidor correspondiente a los datos almacenados del usuario, y el Session ID se almacena en una cookie, y el cliente llevará esto consigo cada vez que se solicite
Cookie, el servidor encuentra los datos almacenados en el lado del servidor según el ID de sesión en la cookie.
FormsAuthentication es proporcionado por Microsoft para que nosotros, los desarrolladores, lo usemos para la autenticación. A través de esta autenticación, podemos almacenar el nombre de usuario y algunos datos de usuario en cookies,
La autenticación básica de identidad y rol puede lograrse fácilmente mediante ajustes básicos de condición.
El efecto que se logra aquí es implementar el control de acceso basado en roles usando el sistema Authorize sin necesidad de ser miembros.
1. Crear un ticket
Después de iniciar sesión, el ID del usuario y el rol correspondiente (para múltiples roles, separados) se almacenan en el ticket.
Cifra el ticket con FormsAuthentication.Encrypt.
Guarda el ticket cifrado en la cookie de Respuesta (el js cliente no necesita leer esta cookie, por lo que es mejor configurar HttpOnly=True para evitar que ataques del navegador roben y forjen cookies). De este modo, podrás leerlo desde la cookie de Solicitud la próxima vez.
Una demo sencilla es la siguiente:
bool isPersistent, //si persiste (se configura según sea necesario, si se configura en persistencia, la opción Expires de la cookie debe estar al enviar una cookie)
El sexto parámetro de FormsAuthenticationTicket almacena la cadena userData de tipos, donde se almacena el ID de rol del usuario actual, separado por una coma.
Al iniciar sesión con un nombre de usuario "test", aparece una cookie de registro en el cliente
2. Obtener información sobre la certificación
Después de iniciar sesión, en la página de contenido, podemos obtener la información de uname a través del User.Identity.Name de la solicitud actual, o podemos descifrar la cookie en la solicitud para obtener el ticket, y luego obtener uname y userData (es decir, la información de ID de rol almacenada previamente) de ella.
3. Realizar el control de acceso a permisos mediante atributos de anotación
Configurar, activar la autenticación de formularios y la gestión de roles en web.config
Cuando añadimos propiedades de anotación a Controller y Action, ¿de dónde obtenemos el Role establecido? Como no usamos la autenticación basada en membresía, también vamos a crear un RoleProvider personalizado. El nombre es CustomRoleProvider, que se hereda de RoleProvider. Aquí tienes la creación de tu propio archivo CustomRoleProvider.cs en la carpeta Helper bajo MVCApp.
Hay muchos métodos abstractos en RoleProvider, y solo implementamos el método GetRolesForUser para obtener roles de usuario. El rol de usuario aquí puede consultarse desde la base de datos según el ID de usuario obtenido, o el que se almacena en la sesión o en la cookie. Aquí ya he guardado el rol en los userData del ticket, así que vamos a sacarlo del ticket.
Si es necesario, añadir atributos de anotación al Controlador o Acción validado; por ejemplo, esta Acción solo permite el acceso con un RoleID de 1, 2 o 3, y el RoleID del usuario actual es (7, 1, 8), lo que significa que el usuario tiene derecho a acceder.
P.D. :1. El ticket se almacena en la fecha de caducidad de la cookie, y si el navegador está cerrado para recordar el ticket actual, los parámetros pueden establecerse cuando se instancia el FormsAuthenticationTicket.
2. La adquisición de Rol puede leerse directamente desde la base de datos sin almacenarse en los userData del ticket, y userData puede almacenar otra información.
3. Si quieres configurar de forma flexible los roles de acceso permitido de Controller y Action, puedes personalizar el método OnAuthorization en la anulación AuthorizeAttribute, en la que se utiliza el método
Lee el ID de rol permitido en la página actual y comprueba según el ID de rol del usuario actual. De este modo, se realiza la configuración flexible del rol.
4. La información del ticket se almacena finalmente en la cookie, y la seguridad sigue estando a tu discreción; personalmente creo que es mejor guardar el UserID y el RoleID en la sesión.
|
Publicado en 19/7/2018 17:31:14
|
|
|
