HTTP, que significa Protocolo de transferencia de hipertexto, es el protocolo fundamental utilizado para la comunicación en la web. Está diseñado para no tener estado, lo que significa que cada solicitud de un cliente (como un navegador web) a un servidor se procesa de forma independiente, sin memoria de interacciones anteriores. Una vez procesada una solicitud, el servidor no retiene ningún estado (o memoria) de esa solicitud.

Si bien la apatridia simplifica el protocolo y lo hace más escalable, plantea desafíos para la creación de aplicaciones web interactivas y personalizadas. Por ejemplo, sin mantener el estado, una aplicación web no podría recordar fácilmente las acciones, preferencias o estados de autenticación anteriores de un usuario en diferentes páginas web.

En aplicaciones típicas basadas en servidor (como las creadas con Django), se inicia una nueva sesión cuando un usuario (o más específicamente, el navegador de un usuario) interactúa por primera vez con la aplicación. Una sesión es una forma de almacenar datos para la interacción de ese usuario en particular con el servidor.

Cuando se crea una sesión, el servidor envía un pequeño fragmento de datos llamado "cookie de sesión" al navegador del usuario. Esta cookie contiene un identificador único llamado "ID de sesión". Este ID es lo que utiliza el servidor para reconocer y diferenciar entre diferentes usuarios (o más exactamente, diferentes sesiones de navegador).

La cookie de sesión se almacena en el navegador del usuario y se envía de regreso al servidor con cada solicitud posterior, lo que permite al servidor mantener una sesión consistente en múltiples solicitudes desde el mismo navegador.

Los componentes del middleware se ejecutan en orden durante las fases de solicitud y respuesta. Cuando llega una solicitud, el middleware de sesión toma el ID de sesión de la cookie del cliente (si está presente) y recupera los datos de sesión asociados del motor de sesión configurado (base de datos, archivo, caché, etc.). Luego hace que estos datos estén disponibles como request.session durante el procesamiento de la vista.

# Middleware in settings.py
MIDDLEWARE = [
...
django.contrib.sessions.middleware.SessionMiddleware
...
]

Después de la migración, Django crea una tabla en la base de datos para las sesiones.

En Django, cada solicitud de usuario al servidor se encapsula en un objeto de solicitud. Este objeto incluye un atributo denominado request.session. Funciona de manera similar a un diccionario de Python, lo que nos permite almacenar, recuperar y administrar datos utilizando pares clave-valor.

Para fines de demostración, creé una nueva aplicación (cookie de sesión) en el proyecto. 

Aquí, he creado una vista que esencialmente cuenta la cantidad de veces que un usuario visita la URL.

# views.py

from django.http import HttpResponse
from django.template import Template, Context
from django.views.decorators.cache import never_cache

@never_cache
def sessionvisit_view(request):
    n_visits = int(request.session.get('n_visits', 0)) + 1
    t = Template('<h1>Total visits: {{n_visits}}</h1>')
    c = Context({"n_visits": request.session["n_visits"]})
    request.session["n_visits"] = n_visits
    return HttpResponse(t.render(c))

Cada vez que actualizo la página, el recuento aumenta.

En la tabla django_session, puedo encontrar las claves de sesión y los datos.

También podemos mostrar los atributos de la sesión en el navegador web (usando el encabezado Set-Cookie). Así, el navegador almacena estos datos en cookies y cada vez que realiza una solicitud al servidor, esta información se transmite dentro del encabezado de la cookie.

session_data es una cadena codificada (base64). Podemos decodificarlo.

import base64
import json

session_str = "eyJuX3Zpc2l0cyI6MTR9:1rQVYV:tvm4LNPRtDXalmCcaR3cXeIMgjj3c8BqzwDca0GdK0U"

# Split the string to get the base64 portion
base64_data = session_str.split(":")[0]

# Pad the string if necessary
padded_base64_data = base64_data + '=' * (-len(base64_data) % 4)

# Decode the base64 string
decoded_data = base64.b64decode(padded_base64_data)

# Assuming the decoded data is JSON serialized
deserialized_data = json.loads(decoded_data)

print(deserialized_data)

"""
{'n_visits': 14}
"""

Las sesiones y las cookies son componentes clave en la gestión de datos de estado y de usuario en aplicaciones web, pero tienen diferentes propósitos y operan de distintas maneras.

Ubicación de almacenamiento

• Cookies: Almacenadas en el lado del cliente, es decir, en el navegador web del usuario.
• Sesiones: almacenadas en el lado del servidor. El ID de sesión, que es una referencia a los datos del lado del servidor, puede almacenarse en una cookie del lado del cliente.

Seguridad

• Cookies: como se almacenan en el lado del cliente, las cookies son más vulnerables a amenazas de seguridad como manipulación y escuchas ilegales. Los datos sensibles no deben almacenarse directamente en las cookies.
• Sesiones: Generalmente más seguras ya que los datos se almacenan en el servidor. Solo se intercambia el ID de la sesión con el cliente, lo que reduce el riesgo de exposición de datos confidenciales.

Tamaño

• Cookies: de tamaño limitado (normalmente 4 KB). No apto para almacenar grandes cantidades de datos.
• Sesiones: Pueden almacenar mayores cantidades de datos ya que no están sujetas a las mismas limitaciones de tamaño que las cookies.

Casos de uso

• Cookies: ideales para almacenar pequeños fragmentos de información no confidencial, como preferencias o configuraciones del usuario.
• Sesiones: más adecuado para gestionar la autenticación de usuarios, almacenar datos específicos del usuario durante la sesión web y manejar datos confidenciales.

Artículo original:

https://awstip.com/django-sessions-70a40aaeaa28