Seguimiento de Sesiones HTTP
Dado que HTTP es un protocolo sin estado, cuando un cliente realiza un número de solicitudes al servidor, ¿cómo el servidor identifica de forma única las solicitudes de un cliente en particular durante un período de tiempo, por ejemplo, t1, t2, t3?.
Navegué por la web y me encontré con términos como id de sesión, reescritura de URL y cookies. Pero sería genial si alguien lo explica de una mejor manera. ¿Específicamente qué parte de la solicitud y respuesta HTTP se usaría para el seguimiento de sesiones?
6 answers
Como mencionaste, las formas comunes de implementar el seguimiento de sesión HTTP incluyen la reescritura de URL y las cookies. El seguimiento de sesiones básicamente requiere que se mantenga un ID de sesión en varias solicitudes al servidor. Esto significa que cada vez que un cliente determinado realiza una solicitud al servidor, pasa el mismo ID de sesión. El servidor puede usar este ID para buscar la información de sesión que mantiene.
Cuando se utilizan cookies, el servidor le pide al cliente que almacene una cookie configurando el Set-Cookie HTTP encabezado de respuesta. Esta cookie contiene el ID de sesión único asignado a ese cliente-en este ejemplo la cadena 'ABAD1D':
Set-Cookie: JSESSIONID=ABAD1D;path=/
La cookie es enviada de vuelta al servidor por el cliente utilizando el encabezado de solicitud HTTP Cookie en cada solicitud y, por lo tanto, el servidor es informado en cada solicitud del ID de sesión asignado actualmente al cliente.
Cookie: JSESSIONID=ABAD1D
Cuando se utiliza la reescritura de URL, este mismo ID de sesión se envía en algún lugar de la URL. Una vez más, el servidor extrae el ID de sesión de la URL para que pueda buscar la sesión de un cliente en particular:
http://my.app.com/index.jsp;JSESSIONID=ABAD1D
Sin embargo, el servidor también debe asegurarse de que cualquier URL en las páginas web enviadas al cliente también se reescriban para contener ese ID de sesión de cliente en particular. Como el ID de sesión está codificado en las URL, este método de seguimiento de sesiones es transparente para el navegador. A menudo, un servidor recurrirá a la reescritura de URL si descubre que no puede establecer una cookie de sesión en el cliente, lo que implica que el cliente no soporte / permitir cookies.
Tenga en cuenta que las sesiones pueden expirar. Esto significa que si el servidor no 've' un ID de sesión dado durante un período de tiempo, puede eliminar los datos de sesión para preservar los recursos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-11-16 09:06:21
Específicamente qué parte del HTTP solicitud y respuesta se utilizarían para ¿seguimiento de sesión?
En la respuesta HTTP, el servidor puede establecer una cookie. Lo hace con el encabezado Set-Cookie. Por ejemplo:
Set-Cookie: session=12345; path=/
A continuación, el cliente devuelve el valor de todas las cookies que coinciden con las propiedades que se establecieron junto con la cookie, que pueden incluir la ruta (como se indica anteriormente) y el dominio, y que aún no han caducado.
La cookie se envía de vuelta al servidor como parte de las cabeceras HTTP. Por ejemplo:
Cookie: session=12345
No se devuelve ninguna información de la propiedad original con la cookie.
Una cookie única permite al servidor asociar una clave única con una instancia de navegador en particular. El servidor puede usar esa clave como un índice en una tabla hash o una tabla de base de datos que contiene información de estado única por usuario.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-11-16 08:57:04
El seguimiento de la sesión es algo del lado del servidor.
Un servidor web emite algún identificador de sesión que se devuelve al navegador. El navegador envía este identificador de sesión junto con cada solicitud.
Esto probablemente se haga utilizando cookies de forma transparente para el usuario.
El manejo de la sesión se realiza en la mayoría de los casos enviando una cookie al cliente. esa cookie se enviaría de vuelta al servidor en cada solicitud de ese cliente en particular.
El session id se asociará con algunos recursos en el lado del servidor (archivo,espacio ram) para que el servidor al leer el session id en la cookie pueda encontrar este recurso y luego saber qué cliente era.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-11-16 08:43:55
Tomando ASP.NET como ejemplo, ref Fig. 1 en
Http://www.codeproject.com/KB/aspnet/SessionTimeoutOnDNN.aspx
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-11-16 09:22:23
Encuentra suficientes detalles aquí
Las sesiones HTTP son el enfoque recomendado. Una sesión identifica las solicitudes que se originan desde el mismo navegador durante el período de conversación. Todos los servlets pueden compartir la misma sesión. El JSESSIONID es generado por el servidor y se puede pasar al cliente a través de cookies, reescritura de URL (si las cookies están desactivadas) o mecanismo SSL incorporado. Se debe tener cuidado para minimizar el tamaño de los objetos almacenados en la sesión y los objetos almacenado en sesión debe ser serializable. En un servlet Java la sesión se puede obtener de la siguiente manera:
HttpSession session = request.getSession(); //devuelve la sesión actual o una nueva sesión
Las sesiones se pueden agotar (configuradas en web).xml) o invalidado manualmente.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-12-16 18:11:08