Anteriormente demostré cómo implementar sesiones en Werkzeug, las cuales pueden ser utilizadas dentro de aplicaciones Flask (pues está basado en Werkzeug). Sin embargo, Flask provee su propia implementación de sesiones implementadas utilizando cookies. Este artículo explica su uso básico y funcionamiento.

El objeto session de Flask implementa sesiones utilizando cookies, por ende no se almacena información alguna en el servidor, lo cual mejora la escalabilidad de la aplicación. Sin embargo, a fin de implementar el comportamiento de sesión utilizando cookies, es necesario lograr que los clientes no puedan modificarlas. Para ello, las cookies de sesión son cifradas con una clave privada configurada en la aplicación del lado servidor. De esta forma los clientes no tienen acceso a la cookie (ni siquiera de lectura pues están encriptadas) y sólo la envían y reciben de la aplicación en cada solicitud/respuesta.

Vamos directo al grano y veamos cómo implementar sesiones en una aplicación Flask.

Para empezar es necesario importar el objeto session:


from flask import Flask, session

application = Flask(__name__)

El siguiente paso consiste en definir la clave privada de cifrado de cookies. Típicamente es recomendable utilizar alguna cadena aleatoria.

application.secret_key = "1234"

Es posible generar strings aleatorios desde línea de comandos en Linux:

$ cat /dev/urandom | LANG=C tr -dc '[:alnum:]' | head -c 32 ; echo

O en FreeBSD de la siguiente forma:

% cat /dev/urandom | env LANG=C tr -dc '[:alnum:]' | head -c 32 ; echo

Utilizar la salida como clave secreta (secret_key) de encriptación.

El último paso en la configuración de las sesiones consiste en establecerlas como permanentes:

@application.before_request
def session_management():
  session.permanent = True

De esta forma no tienen fecha de expiración. De lo contrario las sesiones mueren al cerrar el navegador Web.

A partir de este punto es posible comenzar a utilizar las sesiones. Por ejemplo, el primer paso consiste en inicializar la sesión al autenticar el usuario (/flask/login):

@application.route("/flask/login")
def login():
  session.clear()
  session["user"] = "pepe"
  session["auth"] = 1
  return index()

La clave "user" almacena el nombre de usuario y la clave "auth" indica si ha sido autenticado con éxito o no.

Luego es posible recuperar datos de la sesión de la siguiente forma:

@application.route("/flask/")
def index():
  # Recever username from session
  try:
    user = session["user"]
    auth = session["auth"]
  except:
    user = "unknown"
    auth = 0
  # Hacer algo si auth == 0
  # Por ejemplo cargar el template de login
  return "<p>¡Hola %s!</p>" % user

Finalmente, si se desea blanquear la sesión (por ejemplo al hacer logout), simplemente se invoca nuevamente a session.clear():

@application.route("/flask/logout")
def logout():
  session.clear()
  session["user"] = "unknown"
  session["auth"] = 0
  return index()

Eso es todo, bastante sencillo, casi similar a $_SESSION en PHP.

Sesiones VS. cookies

Ahora analicemos las ventajas y desventajas de utilizar sesiones con Werkzeug (verdaderas sesiones server-side) VS. las sesiones de Flask implementadas con cookies (client-side):

Sesiones (server-side)

Ventajas:

  • Generalmente más fáciles de utilizar.
  • Almacenamiento prácticamente ilimitado.
  • No requieren autorización del usuario (Ley de Cookies).

Desventajas:

  • Más difíciles de escalar (requieren espacio y gestión del lado servidor).
  • Dependiendo de la implementación, podrían perderse todas las sesiones al reiniciar el servidor. Por ejemplo si se almacenan como archivos en un directorio temporal que es "limpiado" en cada reinicio.
  • No son RESTful.

Cookies (client-side)

Ventajas:

  • Escalabilidad: todos los datos se almacenan en el navegador. Diferentes solicitudes pueden pasar a través de un balanceador de carga hacia diferentes servidores, y todos ellos contarán con la información necesaria para procesar cada solicitud sin inconvenientes.
  • Puede ser accedidas mediante JavaScript desde los navegadores (salvo que se utilice la opción HttpOnly).
  • Al no estar alojadas del lado servidor no hay riesgos al momento de reiniciar/migrar sistemas.
  • RESTful: las solicitudes no dependen del estado del servidor.

Desventajas:

  • Límite: típicamente se admite un máximo de 50 cookies por dominio, de 4 KB cada una, dependiendo de cada navegador.
  • Se incrementa el tamaño de las solicitudes, por ende el tráfico de red.
  • Se debe tener el cuidado de transmitir las cookies siempre vía HTTPS.

Referencias


Tal vez pueda interesarte


Compartí este artículo