¿Qué son las sesiones? ¿Cómo trabajan?


332

Estoy comenzando a aprender el desarrollo de aplicaciones web, usando Python. Me encuentro con los términos 'cookies' y 'sesiones'. Entiendo las cookies porque almacenan información en un par de valores clave en el navegador. Pero tengo un poco de confusión con respecto a las sesiones, en una sesión también almacenamos datos en una cookie en el navegador del usuario.

Por ejemplo: inicio sesión con username='rasmus'y password='default'. En tal caso, los datos se publicarán en el servidor que se supone que debe verificar e iniciar sesión si está autenticado. Sin embargo, durante todo el proceso, el servidor también genera una ID de sesión que se almacenará en una cookie en mi navegador. Ahora el servidor también almacena esta ID de sesión en su sistema de archivos o almacén de datos.

Pero basándome solo en la ID de sesión, ¿cómo podría saber mi nombre de usuario durante mi recorrido posterior por el sitio? ¿Almacena los datos en el servidor como un dict donde la clave sería una ID de sesión y detalles como username, emailetc. serían los valores?

Me estoy confundiendo bastante aquí. Necesitas ayuda.


99
"¿Almacena los datos en el servidor como un dict donde la clave sería una identificación de sesión y los detalles como nombre de usuario, correo electrónico, etc. serían los valores?" ...si. El 'dict' podría ser una base de datos relacional, pero así es básicamente cómo funciona.
bobince

14
Yo también quería entender las sesiones web, ahora lo entiendo. Terminé escribiendo mi propia wiki si eso es de alguna ayuda: machinesaredigging.com/2013/10/29/how-does-a-web-session-work
eloone

En caso de que no lo sepa: el almacenamiento de la contraseña en el lado del cliente no es seguro, incluso si la contraseña está cifrada (de hecho, no hace ninguna diferencia. Cracker puede ingresar directamente la contraseña cifrada creando una cookie falsa). son mejores formas de almacenar el estado de inicio de sesión.
cytsunny

Respuestas:


400

Debido a que HTTP no tiene estado, para asociar una solicitud a cualquier otra solicitud, necesita una forma de almacenar datos de usuario entre solicitudes HTTP.

Las cookies o los parámetros de URL (por ejemplo, http://example.com/myPage?asd=lol&boo=no ) son formas adecuadas de transportar datos entre 2 o más solicitudes. Sin embargo, no son buenos en caso de que no desee que los datos sean legibles / editables en el lado del cliente.

La solución es almacenar ese lado del servidor de datos, asignarle un "id" y dejar que el cliente solo sepa (y devuelva en cada solicitud http) ese id. Ahí tienes, sesiones implementadas. O puede usar el cliente como un almacenamiento remoto conveniente, pero cifraría los datos y mantendría el lado secreto del servidor.

Por supuesto, hay otros aspectos a tener en cuenta, como si no quieres que las personas secuestren las sesiones de otros, quieres que las sesiones no duren para siempre sino que expiren, y así sucesivamente.

En su ejemplo específico, la identificación de usuario (podría ser nombre de usuario u otra identificación única en su base de datos de usuarios) se almacena en los datos de la sesión, del lado del servidor, después de una identificación exitosa. Luego, por cada solicitud HTTP que reciba del cliente, la identificación de la sesión (dada por el cliente) le indicará los datos de sesión correctos (almacenados por el servidor) que contienen la identificación de usuario autenticada, de esa manera su código sabrá a qué usuario está hablando con


3
"no desea que esos datos se mantengan del lado del cliente". Por qué no? Si utiliza una criptografía sólida, puede dejar que el cliente mantenga los datos de la sesión cifrados y almacenados en una cookie. Esto simplifica enormemente la ampliación a múltiples nodos ya que los servidores no necesitan 'recordar' nada.
Matt Harrison

55
@MattHarrison, ¿cómo descifraría los datos sin "recordar nada" del lado del servidor? Intenté ampliar este tema en mi respuesta de todos modos.
Luke404

2
@MattHarrison tenga en cuenta que almacenar muchos datos del lado del usuario aumentará su tráfico.
nitsas

55
¿No podría un tercero actuar como usuario si pudiera interceptar la clave de sesión del usuario? Suponiendo que el sitio no usa HTTPS, parece que un tercero podría enmascararse como el usuario con una clave de sesión incluso si la clave está encriptada. El servidor simplemente lo descifraría.
user137717

2
@ user137717 sí, esa es una posibilidad si permite el acceso a la sesión a literalmente "todos los que presentan la identificación de sesión correcta". Puede establecer una serie de restricciones, una de las más fáciles y más comunes es almacenar la IP del cliente en la sesión: si un cliente de otra ip presenta la misma identificación de sesión, marque eso como falsificado y elimine la sesión.
Luke404

110

Explicación simple por analogía

Imagina que estás en un banco, tratando de sacar algo de dinero de tu cuenta. Pero está oscuro; el banco está completamente negro: no hay luz y no puedes ver tu mano frente a tu cara. Estás rodeado de otras 20 personas. Todos ellos parecen iguales. Y todos tienen la misma voz. Y todos son potenciales malos. En otras palabras, HTTP no tiene estado.

Este banco es un tipo de banco divertido, por el simple argumento de cómo funcionan las cosas:

  1. espera en línea (o en línea) y habla con el cajero: hace una solicitud para retirar dinero, y luego
  2. tienes que esperar un momento en el sofá y 20 minutos después
  3. tienes que ir y recoger tu dinero del cajero.

Pero, ¿cómo te distinguirá el cajero de los demás?

El cajero no puede verlo o reconocerlo fácilmente, recuerde, porque las luces están apagadas. ¿Qué pasa si su cajero le da su retiro de $ 10,000 a otra persona, la persona equivocada? Es absolutamente vital que el cajero pueda reconocerlo como el que realizó el retiro, para que pueda obtener el dinero (o recurso) que solicitó.

Solución:

Cuando te apareces por primera vez al cajero, él o ella te dice algo en secreto:

"Cuando me hables", dice el cajero, "primero debes identificarte como GNASHEU329, de esa manera sé que eres tú".

Nadie más conoce la contraseña secreta.

Ejemplo de cómo retiré efectivo:

Así que decido ir y relajarme durante 20 minutos y luego ir al cajero y decir "Me gustaría cobrar mi retiro"

El cajero me pregunta: "¿quién eres?"

"¡Soy yo, señor George Banks!"

"¡Pruébalo!"

Y luego les digo mi contraseña: GNASHEU329

"¡Ciertamente, señor Banks!"

Así es básicamente cómo funciona una sesión. Permite que uno se identifique de forma única en un mar de millones de personas. Debe identificarse cada vez que trata con el cajero.

Si tiene alguna pregunta o no está claro, publique un comentario e intentaré aclararlo.

Explicación a través de imágenes:

Sesiones explicadas a través de Picture


99
Me encanta esta explicación: en su analogía, ¿cómo evitaría que otras personas escuchen a escondidas y también escuchen la contraseña secreta que le dice el cajero? En otras palabras, si se roba el session_id, ¿no sería posible que alguien imite sus credenciales?
wmock

El secuestro de sesión de @wmock es ciertamente un problema: ¡mira esto! owasp.org/index.php/Session_hijacking_attack
BKSpurgeon

2
hermoso ejemplo !! ¡se compartirá con mentes ansiosas que buscan aprender!
Victor

en su analogía, GNASHEU329es la contraseña del usuario, que genera un token de autenticación que caduca hasta cierto tiempo; ¿Entonces Banks puede usar el token de autenticación para hacer varios retiros sucesivos sin tener que darle su contraseña al cajero repetidamente?
Daniel Lizik

@DanielLizik eres def. entendiendo el concepto! Pero no estoy lo suficientemente informado sobre los flujos de trabajo basados ​​en tokens para darle una respuesta inteligente. El principio general es que el servidor debe poder identificar de alguna manera quién es la persona que realiza la solicitud.
BKSpurgeon

39

"Sesión" es el término utilizado para referirse al tiempo que un usuario navega por un sitio web. Está destinado a representar el tiempo desde su primera llegada a una página en el sitio hasta el momento en que dejan de usar el sitio. En la práctica, es imposible saber cuándo el usuario ha terminado con el sitio. En la mayoría de los servidores hay un tiempo de espera que finaliza automáticamente una sesión a menos que el mismo usuario solicite otra página.

Se crea la primera vez que un usuario conecta algún tipo de ID de sesión (la forma en que se realiza depende del software del servidor web y del tipo de autenticación / inicio de sesión que esté utilizando en el sitio). Al igual que las cookies, esto generalmente ya no se envía en la URL porque es un problema de seguridad. En cambio, se almacena junto con un montón de otras cosas que colectivamente también se conoce como la sesión. Las variables de sesión son como cookies: son pares de nombre-valor enviados junto con una solicitud de una página y devueltos con la página desde el servidor, pero sus nombres se definen en un estándar web.

Algunas variables de sesión se pasan como encabezados HTTP . Se pasan de un lado a otro detrás de las escenas de cada búsqueda de páginas para que no aparezcan en el navegador y le digan a todos algo que puede ser privado. Entre ellos se encuentran USER_AGENT, o el tipo de navegador que solicita la página, el REFERENTE o la página que está vinculada a la página que se solicita, etc. Algunos software de servidor web agregan sus propios encabezados o transfieren datos de sesión adicionales específicos al software del servidor. Pero los estándares están bastante bien documentados.

Espero que ayude.


Sé que en los servidores IIS que uso puedo obtener el nombre de usuario de un encabezado USER_NAME, pero eso puede ser específico de IIS.
Tim Rourke

¿Qué significa el REFERENTE aquí?
Gab 是 好人

@Gab 是 好人 REFERRER generalmente significa una cadena arbitraria que el cliente envía en el encabezado de solicitud HTTP "Referer". Se debe contener la URL del recurso que, ya sabes, a que se refiere el cliente al recurso actual.
Luke404

Gracias, debería , así que no necesariamente. así que creo que la gente suele usar este encabezado con una semántica diferente a la sugerida en el RFC, ¿verdad?
Gab 是 好人

Primero escribiste Like cookies, this usually doesn't get sent in the URL anymorey luego Session variables are like cookies - they're name-value pairs sent along with a request for a page. ¿Qué pasa exactamente? ¿Se envía con la próxima vez que realice alguna solicitud?
KPMG

19

HTTP es un protocolo de conexión sin estado, es decir, el servidor no puede diferenciar entre diferentes conexiones de diferentes usuarios.

De ahí viene la cookie, una vez que un cliente se conecta por primera vez a un servidor, el servidor genera una nueva identificación de sesión, que luego se enviará al cliente como valor de cookie. Y a partir de ahora, esta identificación de sesión identificará esa conexión de cliente, porque dentro de cada solicitud HTTP verá la identificación de sesión adecuada dentro de las cookies.

Ahora, para cada ID de sesión, el servidor mantiene cierta estructura de datos, lo que le permite almacenar datos específicos para el usuario, a esta estructura de datos se puede llamar sesión de forma abstracta.


1
¿Puede aclarar un poco más esto: "Ahora, para cada ID de sesión, el servidor mantiene cierta estructura de datos, lo que le permite almacenar datos específicos del usuario, esta estructura de datos puede llamar a la sesión de forma abstracta". ¿Qué información específica del cliente almacena el servidor?
realPK

¿Puede aclarar un poco más esto: "Ahora, para cada ID de sesión, el servidor mantiene cierta estructura de datos, lo que le permite almacenar datos específicos del usuario, esta estructura de datos puede llamar a la sesión de forma abstracta". ¿Qué información específica del cliente almacena el servidor?
Gab 是 好人

La misma pregunta que la anterior también, sería útil si responde.
Suraj Jain

4

Piense en HTTP como una persona (A) que tiene PÉRDIDA DE MEMORIA A CORTO PLAZO y olvida a cada persona tan pronto como esa persona se pierde de vista.

Ahora, para recordar a diferentes personas, A toma una foto de esa persona y la guarda. La foto de cada persona tiene un número de identificación. Cuando esa persona vuelve a estar a la vista, le dice su número de identificación a A y A encuentra su foto por número de identificación. Y voila !!, A sabe quién es esa persona.

Lo mismo es con HTTP. Está sufriendo PÉRDIDA DE MEMORIA A CORTO PLAZO. Utiliza Sesiones para registrar todo lo que hiciste mientras usabas un sitio web, y luego, cuando vuelves, te identifica con la ayuda de Cookies (Cookie es como un token). La imagen es la sesión aquí, y la identificación es la cookie aquí.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.