Cómo funcionan las sesiones
En mi experiencia, la palabra sesión probablemente ocupa el segundo lugar después de transacción en términos de abuso y, lo que es más interesante, transacción y sesión tienen el mismo significado en algunos contextos.
Sesión suele traducirse como sesión, y su significado original se refiere a una serie de operaciones/mensajes que tienen un principio y un final. Por ejemplo, cuando realizas una llamada, el proceso desde que levantas el teléfono. , marcar para colgar el teléfono se puede llamar una sesión. El significado original del término "sesión" se refiere al período desde la apertura de la ventana del navegador hasta el cierre de la ventana del navegador. La frase más confusa es "el usuario (cliente) durante la sesión", que puede referirse a una sesión. serie de operaciones del usuario (generalmente una secuencia de acciones relacionadas con un propósito específico, como iniciar sesión, comprar un producto y salir de un proceso de compra en línea (a veces llamado transacción), pero también puede referirse a una sola conexión, o puede referirse a un significado1, con una sola diferencia que se puede inferir del contexto 2.
Sin embargo, cuando el término sesión está asociado a un protocolo de red, generalmente significa "orientado a la conexión" y/o. "orientado a la conexión" significa que antes de que las dos partes puedan comunicarse, primero se debe establecer un canal de comunicación, como hacer una llamada telefónica. La comunicación no puede comenzar hasta que la otra parte conteste el teléfono; carta Al escribir una carta, no puede estar seguro de si la dirección de la otra parte es correcta. Es posible que el canal de comunicación aún no se haya establecido, pero para el remitente, la comunicación ya ha comenzado. la capacidad de la parte comunicante para correlacionar una serie de información y hacer que la información sea interdependiente. Por ejemplo, una camarera reconoce a una persona que repite y recuerda que el cliente le debía un dólar a la tienda la última vez que vino. sesión" o "una sesión POP3"
En la era de los servidores web, la Web. La semántica de sesiones en desarrollo se ha ampliado para referirse a una clase de soluciones utilizadas para mantener el estado entre el cliente y el servidor. A veces , sesión también se usa para referirse a la estructura de almacenamiento de dichas soluciones, como "guardar xxx en la sesión". Dado que varios lenguajes utilizados para el desarrollo web brindan soporte para dichas soluciones hasta cierto punto, sesión también se usa para referirse. a la solución de un lenguaje específico en el contexto de ese lenguaje, por ejemplo, javax proporcionado en Java .servlet se usa a menudo como logotipo para tiendas generales como Procter & Gamble, y también se puede usar para especificar una máquina específica bajo un dominio. Por ejemplo, www.google.com o froogle.google.com, puede usar Puffy
La ruta va seguida de la ruta URL del nombre de dominio, como / o /foo, etc. /p>
La ruta y el dominio juntos constituyen el alcance de la cookie.
Si no se establece el tiempo de caducidad, significa que el ciclo de vida de la cookie es la duración de la sesión del navegador. Mientras la ventana del navegador esté cerrada, la cookie desaparecerá. Este tipo de cookie cuyo ciclo de vida es la sesión del navegador se denomina cookie de sesión. Las cookies generalmente no se almacenan en el disco duro, sino en la memoria. no está controlado. Si se establece el tiempo de vencimiento, el navegador guardará la cookie en el disco duro. Cuando el navegador se cierre y se abra nuevamente, la cookie continuará siendo válida hasta que se exceda el tiempo de vencimiento establecido. /p>
Las cookies almacenadas en el disco duro se pueden disfrutar entre diferentes procesos del navegador (como dos ventanas de IE). Cada navegador maneja de manera diferente las cookies almacenadas en la memoria. Para IE, una ventana abierta presionando Ctrl-N en una ventana abierta (o desde el menú Archivo) puede disfrutar de la ventana original, mientras que un proceso de IE recién abierto que utiliza otros métodos no puede disfrutar de la ventana abierta en la memoria; Mozilla Firefox 0.8, todos los procesos y pestañas pueden disfrutar de la misma cookie. En términos generales, las ventanas abiertas mediante window.open en javascript compartirán la cookie de memoria con la ventana original.
La forma en que los navegadores manejan las cookies de sesión no tiene nada que ver con las cookies, lo que a menudo causa grandes problemas a los desarrolladores de aplicaciones web que utilizan mecanismos de sesión.
El siguiente es un ejemplo del encabezado de respuesta de Google para configurar cookies
HTTP/1.1 302 Found
Ubicación:/intl/zh-CN/
Set-Cookie: PREF=ID=0565f77e132de138:NW =1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8 expira=dom, 17 de enero de 2038 19:14:07 GMT ruta=; /; domain= .google.com
Content-Type.text/html
Esto es parte del registro de tráfico HTTP capturado utilizando el software HTTP Sniffer HTTPLook
El navegador se reinicia Las cookies se enviarán automáticamente al acceder a los recursos de Google
Con Firefox, puede observar fácilmente el valor de las cookies existentes.
Utiliza HTTPLook de Firefox para comprender fácilmente cómo funcionan las cookies.
IE también se puede configurar para que pregunte antes de aceptar cookies.
Este es un cuadro de diálogo que pregunta si se aceptan cookies.
Cuarto: comprender el mecanismo de sesión
El mecanismo de sesión es un mecanismo del lado del servidor en el que el servidor usa una estructura similar a una tabla hash (o puede simplemente usar una tabla hash) para almacenar información.
Cuando el programa necesita crear una sesión para la solicitud del cliente, el servidor primero verificará si la solicitud del cliente ya contiene un identificador de sesión (llamado ID de sesión. Si lo contiene, significa que lo es). ya para el cliente. Se crea una sesión en el cliente y el servidor recuperará la sesión según la identificación de la sesión (o creará una nueva sesión si no se puede recuperar). Si la solicitud del cliente no incluye una ID de sesión, el servidor crea una sesión para el cliente y genera una ID de sesión asociada con esa sesión. El valor del ID de la sesión debe ser una cadena que no sea repetitiva ni fácil de encontrar para imitar el patrón. El ID de la sesión se devolverá al cliente en la respuesta y se guardará.
El ID de la sesión se puede guardar como una cookie para que el navegador pueda reproducir automáticamente este ID en el servidor de acuerdo con las reglas durante la interacción. Normalmente, estas cookies reciben nombres como SEEESIONID y . Por ejemplo, la cookie generada por weblogic para la aplicación web, JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764, se denomina JSESSIONID.
Debido a que las cookies se pueden deshabilitar manualmente, debe haber algún otro mecanismo para devolver el ID de sesión al servidor cuando la cookie está deshabilitada. Una técnica utilizada con frecuencia se llama reescritura de URL, que consiste en agregar directamente la identificación de la sesión al final de la ruta de la URL. Hay dos formas de agregarla. Una es usarla como información adicional en /wls/docs70/webapp/weblogic_xml. .html# La otra es agregarlo a la ruta URL como información adicional en el formato /wls/docs70/webapp/weblogic_xml.html#1036869.
6. Preguntas frecuentes sobre HttpSession
(En esta sección, sesión se refiere a una combinación de ⑤ y ⑥)
1. >
Un malentendido común es que la sesión se crea cuando el cliente accede a ella, pero de hecho, la sesión se crea cuando el programa del lado del servidor llama a la declaración HttpServletRequest.getSession (true), tenga en cuenta que si no existe. Mostrar usando <%@page session="false"%> para cerrar la sesión, luego el archivo JSP agregará automáticamente esta declaración al compilar el Servlet HttpSession session = HttpServletRequest.getSession(true); en JSP.
Debido a que las sesiones consumen recursos de memoria, debes desactivarlo en todos los JSP si no planeas usarlo.
2. Cuándo eliminar la sesión
Basado en la discusión anterior, la sesión se elimina en las siguientes circunstancias: a. El programa llama a HttpSession.invalidate(); La última solicitud del cliente El intervalo de tiempo entre que el cliente recibe el ID de la sesión excede la configuración del tiempo de espera de la sesión o c. El proceso del servidor se detiene (sesión no persistente)
3. el navegador está cerrado
Estricto Por ejemplo, esto es imposible. Puede hacer un pequeño esfuerzo y usar el código javascript window.oncolose en todas las páginas del cliente para monitorear la operación de cierre del navegador y luego enviar una solicitud al servidor para eliminar la sesión, pero en caso de que el navegador falle o cierre el proceso por la fuerza a través de estos métodos no convencionales. significa que todavía no hay nada que puedas hacer.
4. La función de HttpSessionListener
Puede crear un oyente de este tipo para monitorear los eventos de creación y destrucción de sesiones para que pueda tomar medidas cuando dichos eventos ocurran. Tenga en cuenta que el oyente se activa mediante las operaciones de creación y destrucción de sesiones, y no al revés. Oyentes similares relacionados con HttpSession son HttpSessionBindingListener, HttpSessionActivationListener y HttpSessionAttributeListener.
5. Los objetos almacenados en la sesión deben ser serializables.
No es necesario. Se requiere que los objetos sean serializables solo para que la sesión pueda replicarse o persistir en todo el clúster, o para que el servidor pueda intercambiar temporalmente la sesión fuera de la memoria cuando sea necesario. Colocar un objeto no serializable en una sesión de Weblogic Server generará una advertencia en la consola. Una versión de iPlanet en la que trabajé generaría una excepción en la destrucción de la sesión si había objetos no serializables en la sesión, lo cual era extraño.
6. Cómo manejar correctamente la posibilidad de deshabilitar las cookies del lado del cliente
Utilice la reescritura de URL para todas las URL (incluidos hipervínculos, acciones de formulario y URL de redireccionamiento), como [6. ]
/wls/docs70/webapp/sessions.html #100770
7. Al abrir dos ventanas del navegador para acceder a la aplicación, se utilizará la misma sesión o sesiones diferentes
Consulte la discusión sobre cookies en la tercera sección. Para las sesiones, solo se reconoce la identificación pero no la persona. Por lo tanto, diferentes navegadores, diferentes métodos de apertura de ventanas y diferentes métodos de almacenamiento de cookies afectarán este problema. las respuestas marcan la diferencia.
8. Cómo evitar que el usuario abra dos ventanas del navegador provocando confusión en la sesión
Este problema es similar a evitar que el formulario se envíe varias veces y se puede solucionar configurando un token de cliente. Es decir, el servidor genera una ID diferente cada vez y la devuelve al cliente, mientras la guarda en la sesión. El cliente debe enviar un formulario para devolver la ID al servidor. El programa primero compara si la ID devuelta es consistente. el valor guardado en la sesión. Si es inconsistente, explique Acción enviada.
Para obtener información sobre los patrones de la capa de presentación, consulte "Patrones principales de J2EE". Cabe señalar que para las ventanas window.open que usan javascript, generalmente no configure esta identificación o use una identificación separada para evitar que la ventana principal deje de funcionar. Se recomienda no modificar la ventana abierta. no poder configurarlo.
9. Después de cambiar el valor de la sesión en Weblogic Server, ¿por qué necesita llamar a session.setValue nuevamente?
La razón principal para hacer esto es indicar el valor de Weblogic Server. sesión en un entorno de clúster Cambiado, los nuevos valores de sesión deben copiarse a otros procesos del servidor.
10. Por qué se perdió la sesión
Excluyendo el fallo normal de la sesión, la posibilidad de problemas con el servidor en sí debería ser mínima. Por supuesto, el autor también ha añadido un. He encontrado muchos parches para la versión Solaris de iPlanet6SP1; el complemento del navegador es el siguiente problema más probable. El autor también ha encontrado problemas con el complemento 3721. En teoría, los firewalls o los servidores proxy también pueden tener problemas. Problemas con el procesamiento de cookies.
La mayoría de las razones de este problema son errores de programa, el más común de los cuales son errores cuando una aplicación accede a otra aplicación. Discutiremos este tema en la siguiente sección.
7. Disfrute de una sesión entre aplicaciones****
A menudo sucede que un proyecto grande se divide en varios proyectos pequeños para no interferir entre sí. Se requiere que cada proyecto pequeño se desarrolle como una aplicación web separada, pero al final, de repente se descubre que varios proyectos pequeños necesitan disfrutar de cierta información o quieren usar sesiones para implementar SSO (SSO). Diferentes aplicaciones no pueden acceder a las sesiones de las demás. Cada servidor de aplicaciones cumple con esta especificación en la práctica, pero los detalles de la implementación pueden variar y, por lo tanto, los métodos para resolver el disfrute de sesiones entre aplicaciones también pueden variar.
Primero, echemos un vistazo a cómo Tomcat implementa el aislamiento de sesiones entre aplicaciones web. A juzgar por las rutas de cookies establecidas por Tomcat, establece diferentes rutas de cookies para diferentes aplicaciones, por lo que los ID de sesión utilizados por diferentes aplicaciones son diferentes, por lo que incluso si se accede a diferentes aplicaciones desde la misma ventana del navegador, el ID de sesión se envía a El ID de sesión La ventana del navegador también es diferente. Por lo tanto, el ID de sesión enviado al servidor puede ser diferente incluso si accede a diferentes aplicaciones en la misma ventana del navegador.
Basándonos en esta característica, podemos suponer que la estructura de memoria de la sesión en Tomcat es aproximadamente la siguiente.
He utilizado el mismo enfoque con iPlanet antes e imagino que no habrá mucha diferencia entre SunONE e iPlanet. La idea de utilizar este método para resolver problemas del servidor es simple y la implementación real no es difícil. O todas las aplicaciones *** comparten un ID de sesión o las aplicaciones pueden obtener los ID de sesión de otras aplicaciones.
En iPlanet, la única forma de tener un ID de sesión es establecer la ruta de cookie de cada aplicación en / (en realidad /), y luego la aplicación puede usarla como ID de sesión para acceder a otras aplicaciones.
El ID de sesión de la aplicación (NASApp, el directorio raíz de la aplicación).
Nota, Se deben seguir algunas convenciones de programación al operar ****session, como agregar el prefijo de la aplicación antes del nombre del atributo de la sesión, de modo que setAttribute("name", "neo") se convierta en setAttribute("app1.name", "neo " ) para evitar que los conflictos de espacios de nombres se sobrescriban entre sí.
No existe una opción tan conveniente en Tomcat. En Tomcat versión 3, todavía podemos usar algunos métodos para disfrutar de la sesión. Para la versión 4 y superiores, no he encontrado una manera fácil. Sólo podemos utilizar medios de terceros, como el uso de archivos, bases de datos, cookies JMS o de cliente, parámetros de URL o campos ocultos.
Echemos otro vistazo a cómo Weblogic Server maneja las sesiones.
Como puede ver en la captura de pantalla, Weblogic Server establece la ruta de cookies / para todas las aplicaciones, lo que significa que, de forma predeterminada, Weblogic Server puede disfrutar de la sesión. Sin embargo, un pequeño experimento puede demostrar que incluso si diferentes aplicaciones usan la misma sesión, cada aplicación solo puede acceder a las propiedades que establece. Esto muestra que la estructura de memoria de la sesión en Weblogic Server puede ser la siguiente
Para tal estructura, el mecanismo de la sesión en sí no debería poder resolver el problema del disfrute de la sesión. Además de utilizar poderes de terceros, como archivos, bases de datos, JMS o cookies de cliente, parámetros de URL o campos ocultos, existe una forma más conveniente, que consiste en colocar la sesión de la aplicación en el ServletContext, para que otra aplicación Puede obtener una referencia a la aplicación anterior desde ServletContext. El código de muestra es el siguiente:
Aplicación A
context.setAttribute("appA", sesión
Aplicación B
); contextoA = contexto .getContext("/appA");
HttpSession sessionA = contexto.getContext("/appA");