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

Estoy empezando a comenzar a aprender desarrollo de aplicaciones web, usando Python. Me encuentro con los términos ‘cookies’ y ‘sesiones’. Entiendo las cookies porque almacenan cierta información en un par de valores clave en el navegador. Pero tengo una pequeña 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 de sesión usando 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 datastore.

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

Me estoy confundiendo bastante aquí. Necesitas ayuda.

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

Las cookies o los parámetros de URL (por ejemplo, como http://example.com/miPágina?asd=lol&boo=no ) son dos 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, darle un “id” y dejar que el cliente solo conozca (y devuelva cada solicitud http) esa identificación. Aquí tienes, sesiones implementadas. O puede usar el cliente como un conveniente almacenamiento remoto, pero encriptaría los datos y mantendría el lado del servidor secreto.

Por supuesto, hay otros aspectos a considerar, como que no quiere que las personas se apropien de las sesiones de otras personas, quiere que las sesiones no duren para siempre, sino que caduquen, y así sucesivamente.

En su ejemplo específico, la identificación del usuario (podría ser un nombre de usuario u otra identificación única en su base de datos de usuario) se almacena en los datos de sesión, en el lado del servidor, después de una identificación exitosa. Luego, por cada solicitud HTTP que reciba del cliente, la identificación de sesión (proporcionada por el cliente) lo dirigirá a 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á qué usuario está hablando con.

Explicación simple por analogía

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

Este banco es un tipo de banco divertido; por el bien del argumento, así es cómo funcionan las cosas:

  1. esperas en línea (o en línea) y hablas con el cajero: haces una solicitud para retirar dinero, y luego
  2. tienes que esperar brevemente en el sofá, y 20 minutos después
  3. tienes que ir y, de hecho, recolectar tu dinero del cajero.

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

El cajero no puede verlo ni 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 el recurso) que solicitó.

Solución:

Cuando 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 el código secreto.

Ejemplo de cómo dejé el dinero en efectivo:

Así que decidí ir y relajarme durante 20 minutos y luego ir al cajero y decir “Me gustaría recoger mi retirada”.

El cajero me pregunta: “¿quién eres tú?”

“¡Soy yo, señor George Banks!”

“¡Pruébalo!”

Y luego les digo mi clave de acceso: GNASHEU329

“¡Ciertamente, señor Banks!”

Eso básicamente es cómo funciona una sesión. Le permite a uno ser identificado de manera única en un mar de millones de personas. Necesita identificarse cada vez que trata con el cajero.

Si tiene alguna pregunta o no está claro, publique un comentario y trataré de aclararlo.

“Sesión” es el término utilizado para referirse al tiempo de un usuario que navega por un sitio web. Se supone que representa el tiempo transcurrido entre 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 finalizó 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.

La primera vez que un usuario se conecta se crea 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 normalmente 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 y valor que se envían junto con una solicitud de una página y se devuelven con la página del servidor, pero sus nombres se definen en un estándar web.

Algunas variables de sesión se pasan como encabezados HTTP . Se transmiten detrás de escena de cada página para que no aparezcan en el navegador y le dicen a todo el mundo algo que puede ser privado. Entre ellos se encuentran el USER_AGENT, o el tipo de navegador que solicita la página, el REFERRER o la página que se vincula a la página solicitada, 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.

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 id de sesión apropiada 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, esta estructura de datos puede llamar de manera abstracta a la sesión.

Piense en HTTP como una persona (A) que tiene PÉRDIDA DE MEMORIA A CORTO PLAZO y se olvida de 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, esa persona dice que su número de identificación es A y A encuentra su fotografía por número de identificación. ¡Y voila!, A sabe quién es esa persona.

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

    Intereting Posts