Prefacio
El inicio de sesión único se divide en tres mecanismos, que son el protocolo sin estado http, el mecanismo de sesión y el mecanismo de inicio de sesión.
protocolo sin estado http
La aplicación web utiliza la arquitectura de navegador / servidor, http como protocolo de comunicación, http es un protocolo sin estado, cada solicitud del navegador, el servidor se procesará de forma independiente, como se muestra en la siguiente figura, no hay relación entre las tres solicitudes y las respuestas. .
Es decir, de acuerdo con la figura anterior, la solicitud http es un protocolo sin estado.
Mecanismo de sesión
Cuando el navegador accede al servidor de solicitudes por primera vez, el servidor crea una sesión nuevamente y envía los datos al navegador. El navegador guarda la identificación de la sesión y el servidor juzga si es un usuario de la solicitud por la identificación.
El servidor guarda el objeto de la sesión en la memoria, ¿cómo guarda el navegador la identificación de la sesión? Podrías pensar en dos formas
- Solicitar parámetro
- La cookie
toma el id de sesión como parámetro de cada solicitud. El servidor recibe la solicitud y, naturalmente, puede analizar los parámetros para obtener el id de sesión y determinar si es de la misma sesión. Obviamente, este método no es confiable. Luego, el navegador mantiene esta identificación de sesión por sí mismo. El navegador envía automáticamente la identificación de sesión cada vez que se envía una solicitud http. El mecanismo de cookies solo se usa para hacer esto. La cookie es un mecanismo que utiliza el navegador para almacenar una pequeña cantidad de datos. Los datos se almacenan en forma de "clave / valor", y la información de la cookie se adjunta automáticamente cuando el navegador envía una solicitud http.
El mecanismo de sesión de Tomcat, por supuesto, también implementa cookies. Al acceder al servidor de Tomcat, se puede ver una cookie llamada "JSESSIONID" en el navegador. Esta es la identificación de sesión mantenida por el mecanismo de sesión de Tomcat. Se muestra el proceso de respuesta a la solicitud utilizando la cookie en la figura siguiente.
Estado de inicio de sesión
Con el mecanismo de sesión, el estado de inicio de sesión asume que el navegador necesita ingresar un nombre de usuario y contraseña para verificar la identidad la primera vez que el navegador solicita al servidor que verifique la identidad. El usuario que tiene la sesión es un usuario legítimo, y la sesión debe estar marcado como autorizado o conectado. El logo es el siguiente;
HttpSession session = request.getSession();
session.setAttribute("isLogin", true);Cuando el usuario vuelva a visitar, verá el siguiente estado de inicio de sesión
HttpSession session = request.getSession();
session.getAttribute("isLogin");El modelo implementado es el siguiente:
Cada vez que se solicita un recurso protegido se comprueba el estado de inicio de sesión en el objeto de sesión, solo se puede acceder a la sesión con isLogin = true, por lo que se implementa el mecanismo de inicio de sesión.
Comencemos a explicar el método de implementación.
Una forma de lograrlo: cookie de dominio principal
El alcance de la cookie está determinado por el atributo de dominio y el atributo de ruta. El valor válido del atributo de dominio es el nombre de dominio / dirección IP del dominio actual o su dominio principal. En Tomcat, el atributo de dominio tiene como valor predeterminado el nombre de dominio / dirección IP del dominio actual. El valor válido del atributo de ruta es la ruta que comienza con "/". En Tomcat, el atributo de ruta toma por defecto la ruta de contexto de la aplicación web actual.
Si el atributo de dominio de la cookie se establece en el dominio principal del dominio actual, entonces se considera una cookie de dominio principal. La cookie tiene una característica, es decir, la cookie del dominio principal es compartida por el dominio secundario, es decir, el dominio secundario heredará automáticamente la cookie del dominio principal.
Con esta función de Cookie, no es difícil pensar que no es suficiente guardar el ID de sesión (o Token) en el dominio principal. Así es, solo necesitamos establecer el atributo de dominio de la cookie en el nombre de dominio del dominio principal (nombre de dominio principal) y establecer el atributo de ruta de la cookie en la ruta raíz al mismo tiempo, de modo que todas las aplicaciones de subdominio puede acceder a la cookie. Sin embargo, esto requiere que el nombre de dominio del sistema de aplicación se establezca bajo un nombre de dominio principal común, como tieba.baidu.com y map.baidu.com, ambos establecidos bajo el nombre de dominio principal de baidu.com, luego pueden pasar esta forma de lograr el inicio de sesión único.
Método de implementación dos: centro de certificación
Podemos implementar un centro de certificación para tratar estos problemas.
El usuario inicia sesión en el centro de autenticación. Una vez que el inicio de sesión es exitoso, el centro de autenticación registra el estado de inicio de sesión del usuario y escribe el token en la cookie.
El sistema de la aplicación comprueba si hay un Token en la solicitud actual, si no es así, significa que el usuario no ha iniciado sesión en el sistema actual, y luego la página se redirige al centro de autenticación. Dado que esta operación traerá automáticamente la cookie del centro de certificación, el centro de certificación puede saber si el usuario ha iniciado sesión de acuerdo con la cookie. Si el centro de autenticación encuentra que el usuario no ha iniciado sesión, volverá a la página de inicio de sesión y esperará a que el usuario inicie sesión. Si descubre que el usuario ya ha iniciado sesión, no permitirá que vuelva a iniciar sesión. pero volverá a la URL de destino y generará una antes de que el token de salto se empalme detrás de la URL de destino y se envíe de vuelta al sistema de aplicación de destino.
Una vez que el sistema de solicitud obtiene el Token, también debe confirmar la legalidad del Token con el centro de certificación para evitar que los usuarios lo falsifiquen. Una vez que la confirmación es correcta, el sistema de la aplicación registra el estado de inicio de sesión del usuario, escribe el Token en la Cookie y luego libera la visita. (Tenga en cuenta que esta cookie se encuentra en el sistema de aplicación actual y no puede ser accedida por otros sistemas de aplicación). Cuando el usuario accede al sistema de aplicación actual nuevamente, traerá automáticamente este Token. El sistema de aplicación verifica el Token y encuentra que el usuario está iniciado sesión, por lo que no ¿Qué pasó con el centro de certificación?
Un conocido centro de certificación es ApereoCAS. XXL-SSO
Implementación entre dominios de LocalStorage
Cómo compartir ID de sesión (o token) en varios dominios.
La cookie de dominio principal es una buena solución, pero no admite dominios cruzados. Entonces, ¿existen trucos para hacer que las cookies pasen de un dominio a otro?
Desafortunadamente, los navegadores tienen restricciones entre dominios cada vez más estrictas sobre las cookies. El navegador Chrome también agrega un atributo SameSite a las cookies, que casi prohíbe la transmisión de cookies para solicitudes de dominio cruzado (excepto hipervínculos), y solo cuando se utiliza el protocolo HTTPs se puede permitir en solicitudes de dominio cruzado AJAX Aceptar cookies del servidor.
Sin embargo, en el caso de que el front-end y el back-end estén separados, las cookies son completamente innecesarias. Podemos optar por guardar la ID de sesión (o Token) en el LocalStorage del navegador, para que el front-end tome la iniciativa de guardar el LocalStorage cada vez que se envía una solicitud al back-end, los datos se pasan al servidor. Todos estos están controlados por el front-end. Todo lo que debe hacer el back-end es pasar el ID de sesión (o Token) en el cuerpo de respuesta al front-end después de que el usuario inicie sesión correctamente.
En tal escenario, el inicio de sesión único se puede implementar en la interfaz. Una vez que el front-end obtiene el ID de sesión (o Token), además de escribirlo en su propio LocalStorage, también se puede escribir en LocalStorage en varios otros dominios por medios especiales.
El código de muestra es el siguiente:
// 获取 token
var token = result.data.token;
// 动态创建一个不可见的iframe，在iframe中加载一个跨域HTML
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);
// 使用postMessage()方法将token传递给iframe
setTimeout(function () {
iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);
setTimeout(function () {
iframe.remove();
}, 6000);
// 在这个iframe所加载的HTML中绑定一个事件监听器，当事件被触发时，把接收到的token数据写入localStorage
window.addEventListener('message', function (event) {
localStorage.setItem('token', event.data)
}, false);El front-end usa iframe + postMessage () para escribir el mismo Token en LocalStorage bajo múltiples dominios. Cada vez que el front-end envía una solicitud al back-end, leerá activamente el Token de LocalStorage y lo llevará en la solicitud. El mismo token es compartido por varios dominios.
Espero que sea útil que todos aprendan el inicio de sesión único, y los amigos que me gustan pueden ayudar a avanzar y seguir, ¡gracias!