No le presté mucha atención cuando estudiaba antes, pero hoy he vuelto y he estudiado cuidadosamente el ciclo de vida de la sesión.
Las sesiones se almacenan en el lado del servidor y, generalmente, para evitar que estén en la memoria del servidor (para acceso a alta velocidad), Sessinon crea la primera vez que el usuario accede al servidor.Ten en cuenta que solo acceder a JSP, Servlet y otros programas creará una Sesión, y solo acceder a recursos estáticos como HTML e IMAGE no creará una Sesión.
¿Cuándo expira una sesión?
1. El servidor borrará la sesión de la memoria del servidor que ha estado inactiva durante mucho tiempo, y la sesión será inválida. El tiempo de caducidad por defecto de una sesión en Tomcat es de 20 minutos.
2. Llamar al método de invalidación de la Sesión.
Requisitos de sesión para navegadores:
Aunque la sesión se almacena en el servidor y es transparente para el cliente, su funcionamiento normal sigue requiriendo el soporte del navegador del cliente. Esto se debe a que Session necesita usar cookies como identificador. El protocolo HTTP es sin estado, y la sesión no puede ser juzgada por la conexión HTTP para determinar si es el mismo cliente, por lo que el servidor envía una cookie llamada JSESSIONID al navegador cliente, que tiene el valor del id de la sesión (es decir, el valor de retorno de HttpSession.getId()). Session utiliza la cookie para identificar si es el mismo usuario.
Esta cookie es generada automáticamente por el servidor, y su atributo maxAge suele ser -1, lo que significa que solo es válida en el navegador actual, no se comparte entre ventanas del navegador y no será válida cuando el navegador esté cerrado. Por lo tanto, cuando dos ventanas del navegador en la misma máquina acceden al servidor, se generan dos sesiones diferentes. Excepto para ventanas nuevas que se abren con enlaces, scripts, etc. dentro de la ventana del navegador (es decir, no ventanas abiertas con doble clic en iconos del escritorio, etc.). Estas ventanas hijas comparten la cookie de la ventana padre y, por tanto, una sesión.
Nota: Las nuevas sesiones se generan en ventanas de navegador recién abiertas, excepto en las subventanas. La ventana hija comparte la sesión de la ventana madre. Por ejemplo, cuando haces clic derecho en un enlace y seleccionas "Abrir en una nueva ventana" en el menú de acceso directo que aparece, la ventana hija puede acceder a la Sesión de la ventana principal.
¿Qué pasa si el navegador del cliente desactiva las cookies o no las soporta? Por ejemplo, la gran mayoría de los navegadores móviles no admiten cookies. Java Web ofrece otra solución: la reescritura de direcciones URL.
La reescritura de direcciones URL es una solución para clientes que no soportan cookies. El principio de la reescritura de direcciones URL consiste en reescribir la información de id de la sesión del usuario a la dirección URL. El servidor puede analizar la URL reescrita para obtener el id de sesión. De este modo, aunque el cliente no soporte cookies, la sesión puede usarse para registrar el estado del usuario. La clase HttpServletResponse proporciona encodeURL (URL de cadena) para implementar la reescritura de direcciones de URL, lo que determina automáticamente si el cliente soporta cookies. Si el cliente soporta cookies, la URL se generará tal cual. Si el cliente no soporta cookies, el id de la sesión de usuario se reescribe en la URL.
Nota: TOMCAT determina si un navegador cliente soporta cookies en función de si una cookie está incluida en la solicitud. Aunque el cliente puede soportar cookies, dado que no se transportan cookies en la primera petición (porque no hay cookies que puedan), la dirección URL reescrita seguirá teniendo jsessionid en la dirección. El servidor ya ha escrito una cookie en el navegador en la segunda visita, por lo que la dirección URL reescrita no tendrá jsessionid en la dirección.
|
Publicado en 19/4/2015 19:44:59
|
|
|
Publicado en 18/3/2017 16:52:21