¿Qué son las sesiones? ¿Cómo trabajan?
Recién estoy comenzando a aprender sobre desarrollo de aplicaciones web, usando Python. Me encuentro con los términos "cookies" y "sesiones". Entiendo que las cookies almacenan información en un par clave-valor 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 usando username='rasmus'y password='default'. En tal caso, los datos se publicarán en el servidor que se supone debe verificar e iniciar sesión si estoy autenticado. Sin embargo, durante todo el proceso, el servidor también genera un 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ándose solo en el ID de la 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 dictado donde la clave sería un ID de sesión y detalles como username, emailetc. serían 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 datos de usuario entre solicitudes HTTP.
Las cookies o los parámetros de URL (por ejemplo, como 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 esos datos del lado del servidor, darle una "identificación" y dejar que el cliente solo sepa (y devuelva en cada solicitud http) esa identificación. Ahí lo tienes, sesiones implementadas. O puede utilizar 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 considerar, como no querer que las personas se apropien de las sesiones de otros, querer que las sesiones no duren para siempre sino que caduquen, etc.
En su ejemplo específico, la identificación de 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 la 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) le indicará los datos de sesión correctos (almacenados por el servidor) que contienen la identificación de usuario autenticado; de esa manera, su código sabrá qué usuario es. está hablando.
Explicación a través de imágenes:
**Nota al pie: ignorarla por ahora.
Puedes pensar en una sesión como una tarjeta de identificación de biblioteca. Cada vez que va a una biblioteca, les muestra su tarjeta de identificación emitida por esa biblioteca en particular . Ahora pueden comparar quién es usted con los registros almacenados en el archivo.
Vamos a elaborar paso a paso:
Explicación simple por analogía.
Imagínese que está en un banco intentando sacar algo de dinero de su cuenta. Pero está oscuro; El banco está completamente oscuro: no hay luz. Estás rodeado por otras 20 personas. Todos ellos parecen iguales. Y todos tienen la misma voz. Y todo el mundo es un malo potencial. En otras palabras, HTTP no tiene estado.
Este banco es un tipo curioso de banco; a modo de argumento, así es como funcionan las cosas:
- habla con su cajero y solicita retirar dinero, y luego
- tienes que esperar brevemente en el sofá, y 20 minutos después
- usted recoge su dinero del cajero.
¿Pero cómo te distinguirá el cajero de los demás?
Recuerde que el cajero no puede verlo ni reconocerlo fácilmente 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 quien realizó el retiro, para que pueda obtener el dinero (o recurso) que solicitó.
Solución:
Cuando te presentas por primera vez al cajero, él o ella te dice algo en secreto:
"Cuando hables conmigo", dice el cajero, "primero debes identificarte como GNASHEU329; así sabré 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 voy al cajero y digo "Me gustaría cobrar mi retiro".
El cajero me pregunta: "¡¿quién eres??!"
"¡Soy yo, Sr. George Banks!"
"¡Pruébalo!"
Y luego les digo mi contraseña: GNASHEU329
"¡Ciertamente, Sr. Banks!"
Básicamente así es como funciona una sesión. Permite identificarse de forma única en un mar de millones de personas. Debe identificarse cada vez que trate con el cajero.
Diferencia entre sesiones y cookies
Cookie : Puede pensar en una cookie como simplemente una tarjeta de plástico en la que se imprime información. Puedes almacenar cualquier cosa en esa tarjeta, como:
- nombre / edad / sexo / estado civil
- códigos de acceso
Sesiones : Piense en ello como un código de acceso temporal. El código de acceso se almacena en la cookie , pero eso no la convierte en una cookie.
¿Recuerdas el código de acceso en la historia anterior? GNASHEU329. ¿Qué pasaría si el señor Banks fuera astuto y decidiera editar el número, cambiando el último dígito: GNASHEU320? Hay implicaciones de seguridad con esto:
No querrás que nadie pueda alterar fácilmente los códigos de acceso de las personas o poder reproducirlos fácilmente; consulta los ejemplos a continuación:
Preocupaciones de seguridad con las cookies
El banco puede escribir información en su tarjeta, y usted también. Pero esto puede ser peligroso:
name: Ben Koshy
sex: male
bank balance: $1.99 :'(
Si quiero ser astuto, podría editar mi tarjeta de identificación:
name: Ben Koshy
sex: male
bank balance: $1 billion bucks. <------ new line
¡Hurra! Podría imprimir más dinero que Yellen y Powell juntos. Esto presenta un riesgo de seguridad: es por esta razón que los bancos "encriptan" la información de las cookies, de modo que si usted la manipula, EL BANCO LO SABERÍA. Como regla general, nunca debe incluir en una cookie nada que comprometa, por ejemplo, saldos bancarios, ni nada que pueda ser manipulado. El saldo bancario debe almacenarse en el servidor, donde nadie pueda manipularlo directamente.
En este caso, Powell decidió alterar el saldo bancario de su galleta. El banco ahora puede invalidar su sesión y cerrar su sesión de forma permanente:
name: Jerome Powell
title: "independent" bureaucrat - "Chairman of the Fed"
skill: lying to congress;.
session: tampering with the Fed's balance sheet,
criminal inflation, quantitative easing,
insolvent fed, destroying the dollar,
endless bailouts, telling everyone at the NY economic
club that bond yields are rising def. NOT because of
inflation.....riiiiiiight
-> session invalid. log him out the fed, permanently.
¡Adiós señor!
Duplicar sesiones
Piense en cualquier servicio basado en web: facebook, gmail: si tengo su contraseña, tendré acceso a su cuenta. Lo mismo ocurre con las sesiones: si puedo reproducir o recrear su sesión, entonces efectivamente tengo su contraseña y puedo suplantarme.
Esto podría suceder si te vuelves muy descuidado y liberas accidentalmente tu clave privada en Internet. Alguien en Github publicó recientemente (febrero de 2023) algunas claves privadas. Si publicaron la clave_base_secreta de Github, que es un número aleatorio en su aplicación Rails, entonces podría usar esa clave privada para crear sesiones. Y una vez que creo una sesión, puedo hacerme pasar por otra persona.
** Nota al pie: La imagen de arriba no es del todo precisa porque la sesión será asignada por el "servidor"; suele ser un número aleatorio. Quería simplificar la explicación, así que hice un poco de trampa y usé una analogía ligeramente inexacta para que puedas entender el concepto, de forma aproximada. Podemos centrarnos en los detalles más adelante. La analogía con la tarjeta de biblioteca es más precisa. Si quieres ser muy técnico, consulta las especificaciones de cookies: https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html
"Sesión" es el término utilizado para referirse al tiempo que un usuario pasa navegando por un sitio web. Su objetivo es representar el tiempo entre su primera llegada a una página del sitio hasta el momento en que dejan de utilizar el sitio. En la práctica, es imposible saber cuándo el usuario termina 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.
La primera vez que un usuario se conecta, se crea algún tipo de ID de sesión (la forma en que se hace 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 lugar de eso, se almacena junto con un montón de otras cosas que en conjunto también se denominan 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 están definidos 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 escena de cada navegación de página para que no aparezcan en el navegador y le digan a todos algo que puede ser privado. Entre ellos se encuentran USER_AGENT, o tipo de navegador que solicita la página, REFERRER o la página que enlaza con la página solicitada, etc. Algunos software de servidor web agregan sus propios encabezados o transfieren datos de sesión adicionales específicos del software del servidor. Pero los estándar 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 de ahora en adelante, esta identificación de sesión identificará la conexión de ese cliente, porque dentro de cada solicitud HTTP verá la identificación de sesión apropiada dentro de las cookies.
Ahora, para cada ID de sesión, el servidor mantiene alguna estructura de datos, lo que le permite almacenar datos específicos del usuario; esta estructura de datos se puede llamar sesión de manera abstracta.
