Cómo reescribir la URL cuando las cookies están desactivadas
En mi experiencia, el grado de abuso de la palabra sesión probablemente sea superado solo por transacción. Lo que es aún más interesante es que transacción y sesión tienen el mismo significado en algunos contextos.
Sesión, a menudo traducida como conversación en chino, originalmente significa una serie de acciones/información de principio a fin. Por ejemplo, el proceso desde levantar el teléfono y marcar hasta colgar el teléfono se puede llamar sesión. A veces veremos palabras como "Durante una sesión del navegador,..." La palabra sesión aquí se usa en su significado original, refiriéndose al período desde que se abre la ventana del navegador hasta el momento en que se cierra. Lo más confuso es la frase "el usuario (cliente) está en la conversación", que puede referirse a una serie de acciones del usuario (generalmente una serie de acciones relacionadas con un propósito específico, como comprar en línea desde iniciar sesión hasta compra de bienes) al proceso de pago, a veces llamado transacción), pero a veces solo puede referirse a una conexión, o puede referirse al significado ①, la diferencia solo se puede inferir del contexto ②.
Sin embargo, cuando la palabra sesión está asociada a un protocolo de red, normalmente significa dos cosas: orientada a la conexión y/o de mantenimiento del estado. "Orientado a la conexión" significa que ambas partes que se comunican deben establecer un canal de comunicación antes de comunicarse, como hacer una llamada telefónica hasta que la otra parte responda el teléfono. Por el contrario, cuando envía una carta, no puede confirmar si la dirección de la otra parte es correcta y es posible que no se establezca el canal de comunicación. "Estado de mantenimiento" significa que una parte de la comunicación puede correlacionar una serie de mensajes de modo que los mensajes puedan depender unos de otros. Por ejemplo, un camarero podría reconocer a un cliente que regresa y recordar que la última vez el cliente le debía un dólar a la tienda. Ejemplos de este tipo son "sesión TCP" o "sesión pop 3".
En la era del auge de los servidores web, la semántica de sesión en el contexto del desarrollo web se ha ampliado y su significado se refiere a una solución para mantener el estado entre el cliente y el servidor. A veces, la sesión también se usa para referirse a la estructura de almacenamiento de esta solución, como "guardar xxx en la sesión". Debido a que varios lenguajes utilizados para el desarrollo web brindan soporte para esta solución hasta cierto punto, la sesión también se usa en el contexto de un idioma específico para referirse a la solución de ese idioma. Por ejemplo, el javax.servlet proporcionado en Java suele ser equivalente al logotipo de la oficina central, como P&G. También puede especificar una máquina específica en un dominio, como froogle.google.com, que puede ser más flexible.
La ruta es la ruta URL después del nombre de dominio, como / o /foo, etc. , que se puede comparar con el contador blando.
La combinación de ruta y dominio constituye el alcance de la cookie.
Si no se establece el tiempo de caducidad, significa que la vida útil de la cookie es durante la sesión del navegador. La cookie desaparece tan pronto como se cierra la ventana del navegador. Este tipo de cookie cuya duración es la sesión del navegador se denomina cookie de sesión. Las cookies de sesión generalmente no se almacenan en el disco duro, sino en la memoria. Por supuesto, este comportamiento no está especificado en la especificación. Si se establece un tiempo de vencimiento, el navegador guardará las cookies en el disco duro, lo cerrará y luego lo abrirá nuevamente. Estas cookies seguirán siendo válidas hasta que se supere la fecha de caducidad.
Las cookies almacenadas en el disco duro se pueden compartir entre diferentes procesos del navegador, como por ejemplo dos ventanas de IE. Cada navegador tiene diferentes formas de manejar las cookies almacenadas en la memoria. Para IE, presionar Ctrl-N en la ventana abierta (o desde el menú de archivos) se puede compartir con la ventana original, pero los procesos de IE recién abiertos a través de otros métodos no se pueden compartir con las cookies de memoria ya abiertas para Mozilla Firefox0; Todos los procesos y etiquetas pueden * * * disfrutar de la misma cookie. En términos generales, la ventana abierta con window.open de JavaScript compartirá una cookie de memoria con la ventana original.
Al manejar cookies de sesión, los navegadores sólo reconocen las cookies pero no a la persona, lo que a menudo genera grandes problemas a los desarrolladores de aplicaciones web que utilizan el mecanismo de sesión.
El siguiente es un ejemplo de Google configurando un encabezado de respuesta de cookie.
HTTP/1.1 302 encontrado
Ubicación:
set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM= 1098082649:LM=1098082649: S=kaeacfpo 49 RIA_D8;expires=dom, 17 de enero de 2038 19:14:07 GMT;path=/;domain=.google.com
Tipo de contenido: texto/html
Esto es parte del registro de comunicación HTTP capturado por el software de rastreo HTTP HTTPLook.
El navegador enviará cookies automáticamente al acceder nuevamente a los recursos de Google.
Utilizando Firefox, puedes observar fácilmente el valor de las cookies existentes.
Usando HTTPLook con Firefox puedes entender 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 solicita aceptar cookies.
Cuarto, comprenda el mecanismo de sesión
El mecanismo de sesión es un mecanismo del lado del servidor. El servidor utiliza una estructura similar a una tabla hash (es decir, se puede utilizar una tabla hash). para guardar información.
Cuando un programa necesita crear una sesión para una solicitud de un cliente, el servidor primero verifica si la solicitud del cliente ya contiene una identificación de sesión, lo que significa que se ha creado una sesión para este cliente anteriormente. El servidor recuperará esta sesión para usarla según la identificación de la sesión (si no se puede recuperar, se puede crear una nueva sesión). Si la solicitud del cliente no incluye una identificación de sesión, se creará una sesión para el cliente y se generará la identificación de sesión asociada con esa sesión. El valor de la identificación de la sesión debe ser una cadena que no se repita y que no pueda descubrirse ni imitarse fácilmente. La identificación de la sesión se devolverá al cliente para que la guarde en la respuesta.
Se pueden utilizar cookies para guardar este ID de sesión, de modo que el navegador pueda reproducir automáticamente este identificador en el servidor de acuerdo con las reglas durante la interacción. Normalmente, esta cookie se denomina algo así como SEEESIONID y . Por ejemplo, la cookie generada por weblogic para aplicaciones web, jssession id = byok 3 vjfd 75 anpnrf 7 C2 HMD NV 6 qzcebzwienbeierjq 99 zwbwb ng! -145788764, su nombre es JSESSIONID.
Dado que las cookies se pueden deshabilitar artificialmente, debe haber algún otro mecanismo para pasar la identificación de la sesión al servidor cuando la cookie está deshabilitada. Una técnica utilizada con frecuencia se llama reescritura de URL, que consiste en agregar la identificación de la sesión directamente al final de la ruta de la URL. Hay dos formas de adjuntarla. Una es información adicional como la ruta URL, en el formato; jsessionid = byok3vjfd 75 APN RF 7 C2 hmdnv 6 qzcebzwowibyenlerjq 99 zwpbng! -145788764
El otro se agrega a la URL como una cadena de consulta y la expresión es. -145788764
Para los usuarios, no hay diferencia entre estos dos métodos, pero el servidor los maneja de manera diferente al analizar. Usar el primer método también es útil para distinguir la información de identificación de sesión de los parámetros normales del programa.
Para mantener el estado durante toda la interacción, esta identificación de sesión debe incluirse después de cada ruta que el cliente pueda solicitar.
Otra técnica se llama formar campos ocultos. Es decir, el servidor modificará automáticamente el formulario y agregará un campo oculto para que la identificación de la sesión pueda devolverse al servidor cuando se envíe el formulario. Por ejemplo, el siguiente formulario
ltform name = " test form " action = "/XXX " gt
ltinput type="text "
lt; /form gt;
se reescribirá como se pasó antes al cliente.
ltform nombre = " formulario de prueba " acción = "/XXX " gt;
ltinput type = " oculto " nombre = " jsessionid " valor = " byok3vjfd 75 APN RF 7 C2 HMD NV 6 qzcebzwowibyenlerjq 99 zwpbng! -145788764 "
ltinput type="text "
lt/form gt;
Esta tecnología ahora se usa poco. el muy antiguo iPlanet 6 (el predecesor del servidor de aplicaciones Sun One) con el que he tenido contacto utilizaba esta tecnología.
De hecho, esta técnica se puede sustituir simplemente aplicando la reescritura de URL a la acción.
Cuando hablamos del mecanismo de sesión, a menudo escuchamos el malentendido de que "siempre que cierres el navegador, la sesión desaparecerá". De hecho, puedes imaginar el ejemplo de una tarjeta de socio. A menos que el cliente tome la iniciativa de devolver la tarjeta en la tienda, la tienda nunca borrará la información del cliente fácilmente. Lo mismo ocurre con las sesiones. A menos que el programa le indique al servidor que elimine una sesión, el servidor la mantendrá. Cuando el usuario cierra la sesión, el programa normalmente emite instrucciones para eliminar la sesión. Pero el navegador nunca notifica activamente al servidor que se cerrará antes de cerrarlo, por lo que el servidor nunca tiene la oportunidad de saber que el navegador se ha cerrado. La razón de esta ilusión es que la mayoría de los mecanismos de sesión utilizan cookies de sesión para guardar la ID de la sesión, pero la ID de la sesión desaparece después de cerrar el navegador y no se puede encontrar la sesión original al volver a conectarse al servidor. Si la cookie configurada por el servidor se guarda en el disco duro, o el encabezado de solicitud HTTP enviado por el navegador se reescribe de alguna manera y la ID de la sesión original se envía al servidor, la sesión original aún se puede encontrar cuando el navegador se abre de nuevo.
Precisamente porque cerrar el navegador no provoca que se elimine la sesión, el servidor se ve obligado a establecer un tiempo de caducidad para la sesión. Cuando la última sesión utilizada por un cliente es anterior a este tiempo de caducidad, el servidor puede considerar que el cliente ha detenido su actividad y eliminar la sesión para ahorrar espacio de almacenamiento.
Verbo (abreviatura de verbo) Comprender la versión de javax.servlet Si hay objetos no serializables en la sesión, se producirá una excepción cuando se destruya la sesión, lo cual es extraño.
6. ¿Cómo afrontar correctamente la posibilidad de que el cliente prohíba las cookies?
Utilice la reescritura de URL para todas las URL, incluidos hipervínculos, acciones de formulario y URL redirigidas. Véase [6] para más detalles.
7. Cuando abres dos ventanas del navegador para acceder a una aplicación, ¿utilizarás la misma sesión o sesiones diferentes?
Consulte la discusión sobre cookies en la Sección 3. Para una sesión, la identificación es la única forma de identificar a una persona, por lo que diferentes navegadores, diferentes métodos de apertura de ventanas y diferentes métodos de almacenamiento de cookies tendrán un impacto en la respuesta a esta pregunta.
8. ¿Cómo evitar que los usuarios abran dos ventanas del navegador provocando confusión en la sesión?
Este problema es similar a evitar múltiples envíos de un formulario y se puede resolver configurando el token del cliente. Es decir, cada vez que el servidor genera una identificación diferente y la devuelve al cliente y la guarda en la sesión, el cliente también debe devolver esta identificación al servidor al enviar el formulario. El programa primero compara si la identificación devuelta es consistente con el valor guardado en la sesión. Si son inconsistentes, la operación ha sido presentada. Puede consultar el patrón de capa de presentación en el patrón central J2EE. Cabe señalar que para las ventanas abiertas con javascript window.open, esta ID generalmente no se establece o se usa una ID separada para evitar que la ventana principal deje de funcionar. Se recomienda no modificar la ventana abierta por window.open, de modo que no sea necesaria ninguna configuración.
9. ¿Por qué es necesario volver a llamar a session.setValue después de cambiar el valor de la sesión en Weblogic Server?
Esta acción indica principalmente que el valor en la sesión del servidor Weblogic ha cambiado en un entorno de clúster y que el nuevo valor de la sesión debe copiarse a otros procesos del servidor.
10. ¿Por qué se pierde la sesión?
Además del fallo normal de la sesión, la posibilidad del servidor en sí debería ser muy pequeña, aunque lo he encontrado en la versión Solaris de iPlanet6SP1 con algunos parches; en segundo lugar, la posibilidad de conectar el navegador; -ins, el autor también encontró 3721 problemas causados por complementos; en teoría, los firewalls o servidores proxy también podrían tener problemas con el manejo de cookies.
La mayoría de las razones de este problema son errores de programa, el más común de los cuales es acceder a otra aplicación desde dentro de una aplicación. Discutiremos este tema en la siguiente sección.
7. Sesión entre aplicaciones ***Disfrute
Por lo general, un proyecto grande se divide en varios proyectos pequeños. Para no interferir entre sí, es necesario desarrollar cada pequeño proyecto en una aplicación web independiente. Pero al final, de repente descubrí que algunos proyectos pequeños necesitaban compartir información o querían usar sesiones para implementar SSO (inicio de sesión único). El requisito más natural es que las aplicaciones tengan acceso a las sesiones de las demás.
Sin embargo, según la especificación del Servlet, el alcance de la sesión debe limitarse a la aplicación actual y diferentes aplicaciones no pueden acceder a las sesiones de las demás. Cada servidor de aplicaciones se adhiere a esta especificación desde el punto de vista real, pero los detalles de implementación pueden ser diferentes, por lo que los métodos para resolver el intercambio de sesiones entre aplicaciones también son diferentes.
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 en la misma ventana del navegador, enviar el ID de sesión al servidor puede también ser diferente.
Con base en esta característica, podemos inferir que la estructura de memoria de la sesión en Tomcat es aproximadamente la siguiente.
El iPlanet que usé antes también usó el mismo método. Se estima que no habrá mucha diferencia entre SunONE e IPlanet. Para este tipo de servidor, la solución es relativamente sencilla y no difícil de implementar en la práctica. Haga que todas las aplicaciones * * * compartan un ID de sesión o que las aplicaciones obtengan los ID de sesión de otras aplicaciones.
Existe un método muy simple en iPlanet para lograr * * * compartir una identificación de sesión, es decir, la ruta de la cookie de cada aplicación se establece en / (en realidad debería ser /NASApp, que equivale a la raíz de la aplicación).
ltSession-info>
ltPath>/NASApp lt;/path>
lt/session-info>
Debería ser Tenga en cuenta que * * * las operaciones de sesión deben seguir algunas convenciones de programación, 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 set atributo (" app1. name ", " neo") para evitar conflictos de espacio de nombres y sobrescritura mutua.
No existe una opción tan conveniente en Tomcat. En Tomcat versión 3, también podemos tener algunas formas de disfrutar la sesión. En la actualidad, el autor no ha encontrado un método simple por encima de la versión Tomcat. Sólo podemos confiar en el poder de terceros, como el uso de archivos, bases de datos, cookies JMS o de cliente, parámetros de URL o campos ocultos.
Veamos cómo maneja Weblogic Server las sesiones.
Como puedes ver en la captura de pantalla, la ruta de la cookie establecida por Weblogic Server para todas las aplicaciones es /. ¿Significa esto que las sesiones se pueden disfrutar por defecto en Weblogic Server? Sin embargo, un pequeño experimento puede demostrar que incluso si diferentes aplicaciones utilizan la misma sesión, cada aplicación sólo 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, basada en el mecanismo de la sesión en sí, no debería poder resolver el problema del disfrute de la sesión. Además de la ayuda de terceros, como el uso de archivos, bases de datos, JMS o cookies de cliente, parámetros de URL o campos ocultos, un método más conveniente es colocar la sesión de una aplicación en ServletContext para que otra aplicación pueda acceder a ella desde Obtener la referencia. de la aplicación anterior en ServletContext. El código de muestra es el siguiente:
Aplicación a
context.setAttribute("appA ", sesión);
Aplicación b
contextoA = contexto . get contexto("/appA ");
sesión http sesión a =(sesión http)contexta . get atributo(" appA ");
Notable Sí, esto. el uso no es portátil porque según el JavaDoc de ServletContext, el servidor de aplicaciones puede ser seguro porque context.getContext("/appA ");
Entonces, ¿por qué Weblogic Server establece la ruta de cookies de todas las aplicaciones en /? Inicialmente para SSO, todas las aplicaciones que disfrutan de la sesión pueden disfrutar de la información de autenticación. Un simple experimento puede demostrarlo. Cambiar el descriptor weblogic.xml de la aplicación que inició sesión primero y cambiar la ruta de la cookie a /appA requerirá que inicie sesión nuevamente. Incluso, por otro lado, si primero accede a la aplicación utilizando la ruta de cookies de / y luego accede a esta aplicación utilizando la ruta modificada, la información del usuario que inició sesión se perderá. Tenga en cuenta que al realizar este experimento, el método de autenticación debe usar FORM, porque los navegadores y servidores web tienen otros métodos de procesamiento para los métodos de autenticación básicos y la autenticación de la segunda solicitud no se implementa a través de la sesión. Consulte [7] autorización de la SECCIÓN 14.8 para obtener más detalles. Puede modificar el programa de muestra adjunto para realizar estos experimentos.
Ocho.
Resumen
El mecanismo de sesión en sí no es complicado, pero la flexibilidad de su implementación y configuración hace que la situación específica sea compleja y cambiante. Esto también requiere que no podamos considerar simplemente una experiencia o la experiencia de un navegador o servidor como una experiencia universal, sino que siempre debemos analizar la situación específica.