Django proporciona un soporte completo para sesiones anónimas. El marco de trabajo de sesión te permite almacenar y recuperar datos arbitrarios en una base por visitante del sitio. Almacena los datos en el lado del servidor y abstracta la envío y recepción de cookies. Las cookies contienen un ID de sesión – no los datos mismos (a menos que estés utilizando el backend basado en cookie.
Las sesiones se implementan mediante una pieza de middleware.
Para habilitar la funcionalidad de sesión, haz lo siguiente:
Edita el MIDDLEWARE y asegúrate de que contenga 'django.contrib.sessions.middleware.SessionMiddleware'. La configuración predeterminada settings.py creada por django-admin startproject tiene SessionMiddleware activado.
Si no quieres usar sesiones, puedes eliminar la línea SessionMiddleware de MIDDLEWARE y 'django.contrib.sessions' de tus INSTALLED_APPS. Te ahorrará un pequeño poco de sobrecarga.
Por defecto, Django almacena las sesiones en tu base de datos (utilizando el modelo django.contrib.sessions.models.Session). Aunque esto es conveniente, en algunos entornos es más rápido almacenar los datos de la sesión en otro lugar, por lo que Django se puede configurar para almacenar los datos de la sesión en tu sistema de archivos o en tu caché.
Si deseas utilizar una sesión respaldada por base de datos, debes agregar 'django.contrib.sessions' a la configuración de INSTALLED_APPS.
Una vez que hayas configurado tu instalación, ejecuta manage.py migrate para instalar la sola tabla de la base de datos que almacena los datos de la sesión.
Para una mejor rendimiento, es posible que desees utilizar un backend de sesión basado en caché.
Para almacenar los datos de la sesión utilizando el sistema de cache de Django, primero debes asegurarte de haber configurado tu caché; consulta la documentación del caché para obtener más detalles.
Advertencia
Solo debes utilizar sesiones basadas en caché si estás utilizando el backend de caché Memcached o Redis. El backend de caché local-memory no retiene los datos lo suficiente como para ser una buena elección, y será más rápido utilizar sesiones de archivo o base de datos directamente en lugar de enviar todo a través de los backends de caché de archivo o base de datos. Además, el backend de caché local-memory NO es seguro entre procesos, por lo que probablemente no sea una buena elección para entornos de producción.
Si tienes múltiples caches definidos en CACHES, Django utilizará el caché predeterminado. Para utilizar otro caché, establece SESSION_CACHE_ALIAS con el nombre del caché que deseas utilizar.
Una vez que esté configurada tu caché, tienes que elegir entre una caché respaldada por base de datos o una caché no persistente.
La caché de backend de la base de datos (cached_db) utiliza una caché write-through – las escrituras de sesión se aplican tanto a la base de datos como a la caché, en ese orden. Si falla la escritura en la caché, el error es manejado y registrado mediante el logger de sesiones, para evitar que una operación de escritura exitosa falle.
Se han agregado manejo y registro de excepciones al escribir en la caché.
Las lecturas de sesión utilizan la caché, o la base de datos si los datos se han expulsado de la caché. Para utilizar este backend, establece SESSION_ENGINE a "django.contrib.sessions.backends.cached_db", y sigue las instrucciones de configuración para las sesiones respaldadas por base de datos.
El backend de caché (cache) almacena los datos de sesión solo en tu caché. Esto es más rápido porque evita la persistencia de base de datos, pero tendrás que considerar qué sucede cuando se elimina el dato de la caché. La eliminación puede ocurrir si la caché se llena o si se reinicia el servidor de caché, y significará que los datos de sesión se pierden, incluyendo la salida de usuarios. Para utilizar este backend, establece SESSION_ENGINE a "django.contrib.sessions.backends.cache".
El backend de caché puede hacerse persistente utilizando una caché persistente, como Redis con configuración adecuada. Pero a menos que tu caché esté configurada para suficiente persistencia, opta por el backend de la base de datos. Esto evita los casos de borde causados por almacenamiento de datos no confiable en producción.
Para utilizar sesiones basadas en archivos, establece la configuración SESSION_ENGINE a "django.contrib.sessions.backends.file".
También podrías querer establecer la configuración SESSION_FILE_PATH (que tiene un valor predeterminado de salida de tempfile.gettempdir() , lo que probablemente sea /tmp) para controlar dónde Django almacena los archivos de sesión. Asegúrate de verificar que tu servidor web tenga permisos para leer y escribir en esta ubicación.
When SessionMiddleware está activado, cada objeto HttpRequest – el primer argumento de cualquier función de vista Django – tendrá un atributo session, que es un objeto similar a un diccionario.
Puedes leer y escribir en request.session en cualquier punto de tu vista. Puedes editarla varias veces.
Esta es la clase base para todos los objetos de sesión. Tiene los siguientes métodos estándar del diccionario:
Ejemplo: fav_color = request.session['fav_color']
Ejemplo: request.session['fav_color'] = 'azul'
Ejemplo: del request.session['fav_color']. Esto levanta un KeyError si la clave dada no está ya en la sesión.
Ejemplo: 'fav_color' in request.session
Versión asíncrona: aget()
Ejemplo: fav_color = request.session.get('fav_color', 'rojo')
Se agregó la función aget().
await request.session.aset('fav_color', 'red')
Versión asíncrona: aupdate()
Ejemplo: request.session.update({'fav_color': 'rojo'})
La función aupdate() fue agregada.
Versión asíncrona: apop()
Ejemplo: fav_color = request.session.pop('color_favorito', 'azul')
Se agregó la función apop().
Versión asíncrona: akeys()
Se agregó la función akeys().
Versión asíncrona: avalues()
La traducción de los textos es la siguiente:
Versión asíncrona: ahas_key()
ahas_key() función fue agregada.
Versión asíncrona: aitems()
aitems() función fue agregada.
Versión asíncrona: asetdefault()
asetdefault() función fue agregada.
También tiene estas funciones:
Versión asíncrona: aflush()
Elimina los datos de la sesión actual del almacenamiento de sesiones y elimina el cookie de la sesión. Esto se utiliza si deseas asegurarte de que no puedan accederse nuevamente a los datos de la sesión anterior desde el navegador del usuario (por ejemplo, la función django.contrib.auth.logout() la llama).
La traducción de los textos es la siguiente:
Versión asíncrona: aset_test_cookie()
Establece una cookie de prueba para determinar si el navegador del usuario admite cookies. Debido a la forma en que funcionan las cookies, no podrás probar esto hasta la próxima solicitud de página del usuario. Consulte Configuración de cookies de prueba a continuación para obtener más información.
aset_test_cookie() función fue agregada.
Versión asíncrona: atest_cookie_worked()
Devuelve True o False, dependiendo de si el navegador del usuario aceptó la cookie de prueba. Debido a la forma en que funcionan las cookies, deberás llamar a set_test_cookie() o aset_test_cookie() en una solicitud de página previa y separada. Consulte Configuración de cookies de prueba a continuación para obtener más información.
atest_cookie_worked() función fue agregada.
Versión asíncrona: adelete_test_cookie()
Elimina la cookie de prueba. Utiliza esto para limpiar después de ti mismo.
adelete_test_cookie() función fue agregada.
Returns el valor de la configuración SESSION_COOKIE_AGE. Esto puede ser sobrescrito en un backend personalizado de sesión.
Versión asincrónica: aset_expiry()
Establece la hora de expiración para la sesión. Puedes pasar diferentes valores:
Si value es un entero, la sesión expirará después de ese número de segundos de inactividad. Por ejemplo, si se llama a request.session.set_expiry(300), la sesión expiraría en 5 minutos.
Si value es un objeto datetime o timedelta, la sesión expirará en esa fecha/hora específica.
Si value es 0, el cookie de sesión del usuario expirará cuando se cierra el navegador web del usuario.
Si value es None, la sesión recae en la política de expiración global de sesiones.
La lectura de una sesión no se considera actividad para fines de expiración. La expiración de la sesión se calcula a partir del último momento en que la sesión fue modificada.
Se agregó la función aset_expiry().
Versión asincrónica: aget_expiry_age()
Returns el número de segundos hasta que esta sesión expira. Para las sesiones sin una expiración personalizada (o aquellas configuradas para expirar al cierre del navegador), esto será igual a SESSION_COOKIE_AGE.
Esta función acepta dos argumentos de palabra clave opcionales:
modification: última modificación de la sesión, como un objeto datetime. Por defecto es el momento actual.
expiry: información de expiración para la sesión, como un objeto datetime, un int (en segundos) o None. Por defecto es el valor almacenado en la sesión por set_expiry()/aset_expiry(), si existe, o None.
Nota
Este método se utiliza por los backends de sesiones para determinar la edad de expiración de la sesión en segundos al guardar la sesión. No está realmente destinado a su uso fuera de ese contexto.
En particular, aunque es posible determinar la vida restante de una sesión justo cuando tienes el valor correcto modification y la expiry se establece como un objeto datetime, donde sí tienes el valor modification, es más directo calcular la expiración a mano:
expires_at = modification + timedelta(seconds=settings.SESSION_COOKIE_AGE)
Se agregó la función aget_expiry_age().
Versión asíncrona: aget_expiry_date()
Returns la fecha en que esta sesión expirará. Para las sesiones sin una expiración personalizada (o aquellas configuradas para expirar al cierre del navegador), esto será igual a la fecha SESSION_COOKIE_AGE segundos desde ahora.
Esta función acepta los mismos argumentos de palabra clave que get_expiry_age(), y se aplican notas similares sobre su uso.
La traducción de los textos es la siguiente:
Versión asíncrona: aget_expire_at_browser_close()
Devuelve True o False, dependiendo de si la cookie de sesión del usuario expirará cuando el navegador web del usuario sea cerrado.
aget_expire_at_browser_close() función fue agregada.
Versión asíncrona: aclear_expired()
Elimina las sesiones caducadas del almacén de sesión. Este método de clase se llama por clearsessions.
aclear_expired() función fue agregada.
Versión asíncrona: acycle_key()
Crea una nueva clave de sesión mientras se retiene los datos de la sesión actual. django.contrib.auth.login() llama a este método para mitigar contra la fijación de sesión.
acycle_key() función fue agregada.
Por defecto, Django serializa los datos de sesión utilizando JSON. Puedes personalizar el formato de serialización de la sesión mediante la configuración SESSION_SERIALIZER. A pesar de las limitaciones descritas en serializadores personalizados, recomendamos encarecidamente utilizar la serialización JSON sobre todo si estás utilizando el backend de cookies.
Por ejemplo, aquí tienes un escenario de ataque si utilizas pickle para serializar los datos de sesión. Si estás utilizando el backend de sesión de cookie firmada <cookie-session-backend> y la clave secreta SECRET_KEY (o cualquier otra clave de SECRET_KEY_FALLBACKS) es conocida por un atacante (no existe una vulnerabilidad inherente en Django que cause que se filtre), el atacante podría insertar una cadena en su sesión que, cuando se desempaqueta, ejecuta código arbitrario en el servidor. La técnica para hacerlo es simple y está fácilmente disponible en Internet. Aunque la almacenamiento de sesión de cookie firma los datos almacenados en cookies para prevenir la manipulación, un SECRET_KEY filtrado eleva inmediatamente a una vulnerabilidad de ejecución de código remoto.
Un wrapper alrededor del serializador JSON desde django.core.signing. Solo puede serializar tipos de datos básicos.
Además, como JSON solo admite claves de cadena, ten en cuenta que utilizar claves no de cadena en request.session no funcionará como se espera:
>>> # initial assignment
>>> request.session[0] = "bar"
>>> # subsequent requests following serialization & deserialization
>>> # of session data
>>> request.session[0] # KeyError
>>> request.session["0"]
'bar'
De manera similar, los datos que no pueden codificarse en JSON, como bytes no UTF8 como '\xd9' (que levanta UnicodeDecodeError), no pueden almacenarse.
Consulte la sección serializadores personalizados para obtener más detalles sobre las limitaciones de la serialización JSON.
Ten en cuenta que el JSONSerializer no puede manejar tipos de datos Python arbitrarios. Como es a menudo el caso, hay un equilibrio entre conveniencia y seguridad. Si deseas almacenar tipos de datos más avanzados, incluidos datetime y Decimal, en sesiones respaldadas por JSON, necesitarás escribir un serializador personalizado (o convertir tales valores a un objeto serializable para JSON antes de almacenarlos en request.session). Si bien la serialización de estos valores es a menudo sencilla (DjangoJSONEncoder puede ser útil), escribir un deserializador que pueda obtener con fiabilidad lo mismo que pusiste dentro es más frágil. Por ejemplo, correr el riesgo de devolver un datetime que en realidad era una cadena que solo sucedió estar en el mismo formato elegido para datetimes).
Tu clase de serialización debe implementar dos métodos: dumps(self, obj) y loads(self, data), para serializar y deserializar el diccionario de datos de sesión, respectivamente.
Utiliza cadenas de Python normales como claves de diccionario en request.session. Esto es más una convención que una regla estricta.
Las claves del diccionario de sesión que comienzan con un guión bajo están reservadas para uso interno por Django.
No sobreescribas request.session con un nuevo objeto, y no accedas ni establezcas sus atributos. Utilízalo como un diccionario de Python.
Esta vista simplista establece una variable has_commented en True después de que un usuario publique un comentario. No permite a un usuario publicar más de un comentario:
def post_comment(request, new_comment):
if request.session.get("has_commented", False):
return HttpResponse("You've already commented.")
c = comments.Comment(comment=new_comment)
c.save()
request.session["has_commented"] = True
return HttpResponse("Thanks for your comment!")
Esta vista simplista inicia sesión a un «miembro» del sitio:
def login(request):
m = Member.objects.get(username=request.POST["username"])
if m.check_password(request.POST["password"]):
request.session["member_id"] = m.id
return HttpResponse("You're logged in.")
else:
return HttpResponse("Your username and password didn't match.")
…Y esta otra inicia el cierre de sesión de un miembro, según login() anterior:
def logout(request):
try:
del request.session["member_id"]
except KeyError:
pass
return HttpResponse("You're logged out.")
La función estándar django.contrib.auth.logout() realiza un poco más que esto para prevenir la fuga accidental de datos. Llama al método flush() del objeto request.session. Estamos utilizando este ejemplo como una demostración de cómo trabajar con objetos de sesión, no como una implementación completa de logout().
Nota
Los ejemplos en esta sección importan el objeto SessionStore directamente desde la parte trasera django.contrib.sessions.backends.db. En tu propio código, debes considerar importar SessionStore desde el motor de sesión designado por SESSION_ENGINE, como se muestra a continuación:
>>> from importlib import import_module
>>> from django.conf import settings
>>> SessionStore = import_module(settings.SESSION_ENGINE).SessionStore
Está disponible una API para manipular datos de sesión fuera de una vista:
>>> from django.contrib.sessions.backends.db import SessionStore
>>> s = SessionStore()
>>> # stored as seconds since epoch since datetimes are not serializable in JSON.
>>> s["last_login"] = 1376587691
>>> s.create()
>>> s.session_key
'2b1189a188b44ad18c35e113ac6ceead'
>>> s = SessionStore(session_key="2b1189a188b44ad18c35e113ac6ceead")
>>> s["last_login"]
1376587691
SessionStore.create() está diseñada para crear una nueva sesión (es decir, una que no ha sido cargada desde el almacén de sesiones y tiene session_key=None). save() está diseñado para guardar una sesión existente (es decir, una que ha sido cargada desde el almacén de sesiones). Llamar a save() en una nueva sesión también puede funcionar pero tiene una pequeña probabilidad de generar un session_key que coincida con uno existente. create() llama a save() y bucea hasta generar un session_key no utilizado.
Si estás utilizando la parte trasera django.contrib.sessions.backends.db, cada sesión es un modelo normal de Django. El modelo Session está definido en django/contrib/sessions/models.py. Porque es un modelo normal, puedes acceder a las sesiones usando el API de base de datos normal de Django:
>>> from django.contrib.sessions.models import Session
>>> s = Session.objects.get(pk="2b1189a188b44ad18c35e113ac6ceead")
>>> s.expire_date
datetime.datetime(2005, 8, 20, 13, 35, 12)
Los textos traducidos son:
>>> s.session_data
'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
>>> s.get_decoded()
{'user_id': 42}
Por defecto, Django solo guarda en la base de datos de sesión cuando la sesión ha sido modificada – es decir, si alguno de sus valores del diccionario han sido asignados o eliminados:
# Session is modified.
request.session["foo"] = "bar"
# Session is modified.
del request.session["foo"]
# Session is modified.
request.session["foo"] = {}
# Gotcha: Session is NOT modified, because this alters
# request.session['foo'] instead of request.session.
request.session["foo"]["bar"] = "baz"
En el último caso del ejemplo anterior, podemos indicar al objeto de sesión explícitamente que ha sido modificado estableciendo la propiedad modified en el objeto de sesión:
request.session.modified = True
Para cambiar este comportamiento por defecto, establece la configuración SESSION_SAVE_EVERY_REQUEST en True. Cuando está establecido en True, Django guardará la sesión en la base de datos en cada solicitud.
Ten en cuenta que el cookie de sesión solo se envía cuando una sesión ha sido creada o modificada. Si SESSION_SAVE_EVERY_REQUEST está establecido en True, el cookie de sesión se enviará en cada solicitud.
De manera similar, la parte expires del cookie de sesión se actualiza cada vez que se envía el cookie de sesión.
La sesión no se guarda si el código de estado de respuesta es 500.
Puedes controlar si el marco de trabajo de sesión utiliza sesiones de navegador vs. sesiones persistentes con la configuración SESSION_EXPIRE_AT_BROWSER_CLOSE.
Por defecto, SESSION_EXPIRE_AT_BROWSER_CLOSE está configurado en False, lo que significa que las cookies de sesión se almacenarán en los navegadores de los usuarios durante todo el tiempo que dure SESSION_COOKIE_AGE. Utiliza esto si no quieres que la gente tenga que iniciar sesión cada vez que abran un navegador.
Si SESSION_EXPIRE_AT_BROWSER_CLOSE está configurado en True, Django utilizará cookies de navegador de longitud – cookies que caducan tan pronto como el usuario cierre su navegador. Utiliza esto si quieres que la gente tenga que iniciar sesión cada vez que abran un navegador.
Esta configuración es una configuración global por defecto y puede ser sobrescrita a nivel de sesión llamando explícitamente al método set_expiry() de request.session como se describe arriba en using sessions in views.
Nota
Algunos navegadores (por ejemplo, Chrome) proporcionan configuraciones que permiten a los usuarios seguir navegando por sesiones después de cerrar y volver a abrir el navegador. En algunos casos, esto puede interferir con la configuración SESSION_EXPIRE_AT_BROWSER_CLOSE y evitar que las sesiones caducen al cerrar el navegador. Ten en cuenta esto mientras pruebes aplicaciones Django que tienen la configuración SESSION_EXPIRE_AT_BROWSER_CLOSE habilitada.
A medida que los usuarios crean nuevas sesiones en tu sitio web, los datos de sesión pueden acumularse en tu almacenamiento de sesión. Si estás utilizando el backend de base de datos, la tabla django_session de la base de datos aumentará. Si estás utilizando el backend de archivo, tu directorio temporal contendrá un número creciente de archivos.
Para entender este problema, considera lo que sucede con el backend de base de datos. Cuando un usuario inicia sesión, Django agrega una fila a la tabla django_session de la base de datos. Django actualiza esta fila cada vez que los datos de sesión cambian. Si el usuario se desloguea manualmente, Django elimina la fila. Pero si el usuario no se desloguea, la fila nunca se elimina. Un proceso similar sucede con el backend de archivo.
Django no proporciona purgación automática de sesiones caducadas. Por lo tanto, es tu responsabilidad purgar las sesiones caducadas con regularidad. Django proporciona un comando de limpieza de administración para este propósito: clearsessions. Se recomienda llamar a este comando con regularidad, por ejemplo como un trabajo cron diario.
Ten en cuenta que el backend de caché no es vulnerable a este problema, porque los caches eliminan automáticamente los datos caducados. Lo mismo sucede con el backend de cookie, porque los datos de sesión se almacenan en los navegadores de los usuarios.
A continuación, te proporciono las traducciones de los textos originales manteniendo todas sus etiquetas intactas.
ALIAS_DE_CACHÉ_DE_SESIONES
EDAD_DEL_COCHITO_DE_SESIONES
DOMINIO_DEL_COCHITO_DE_SESIONES
HTTPONLY_DEL_COCHITO_DE_SESIONES
NOMBRE_DEL_COCHITO_DE_SESIONES
RUTA_DEL_COCHITO_DE_SESIONES
SAMESITE_DEL_COCHITO_DE_SESIONES
SEGURO_DEL_COCHITO_DE_SESIONES
MOTOR_DE_SESIONES
Los subdominios dentro del sitio pueden establecer cookies en el cliente para todo el dominio. Esto hace posible la fijación de sesiones si se permiten cookies desde subdominios no controlados por usuarios confiables.
Por ejemplo, un atacante podría iniciar sesión en good.example.com y obtener una sesión válida para su cuenta. Si el atacante tiene control sobre bad.example.com, pueden utilizarlo para enviar la clave de sesión a usted ya que se permite a los subdominios establecer cookies en *.example.com. Cuando visite good.example.com, estará conectado como el atacante y podría ingresar inadvertidamente sus datos personales sensibles (por ejemplo, información de tarjeta de crédito) en la cuenta del atacante.
Otra posible vulnerabilidad sería si good.example.com establece su SESSION_COOKIE_DOMAIN en "example.com" lo que causaría que las cookies de sesión de ese sitio se envíen a bad.example.com.
La diccionario de sesión acepta cualquier valor serializable en formato json cuando se utiliza el JSONSerializer.
Los datos de sesión se almacenan en una tabla de la base de datos denominada django_session .
Django solo envía un cookie si lo necesita. Si no estableces ningún dato de sesión, no enviará un cookie de sesión.
SessionStore¶Cuando se trabaja con sesiones internamente, Django utiliza un objeto de almacenamiento de sesión desde el motor de sesión correspondiente. Por convención, la clase del objeto de almacenamiento de sesión se denomina SessionStore y está ubicada en el módulo designado por SESSION_ENGINE.
Todos los subclases de SessionStore disponibles en Django implementan los siguientes métodos de manipulación de datos:
exists()
create()
save()
delete()
load()
clear_expired()
Una interfaz asíncrona para estos métodos se proporciona mediante el envoltorio de sync_to_async(). Pueden implementarse directamente si está disponible una implementación nativa asíncrona:
aexists()
acreate()
asave()
adelete()
aload()
aclear_expired()
Para crear un motor de sesión personalizado o para personalizar uno existente, puede crear una nueva clase que herede de SesiónBase o cualquier otra clase SessionStore existente.
Puede extender los motores de sesión, pero hacerlo con motores de sesión respaldados por base de datos generalmente requiere un poco más de esfuerzo (consulte la siguiente sección para detalles).
Los métodos aexists(), acreate(), asave(), adelete(), aload(), y aclear_expired() fueron agregados.
Se puede crear un motor de sesión personalizado basado en los incluidos en Django (es decir, db y cached_db) heredando AbstractBaseSession y la clase SessionStore.
AbstractBaseSession y BaseSessionManager son importables desde django.contrib.sessions.base_session para que puedan ser importados sin incluir django.contrib.sessions en INSTALLED_APPS.
El modelo de sesión abstracto.
Clave primaria. El campo puede contener hasta 40 caracteres. La implementación actual genera una cadena de 32 caracteres (una secuencia aleatoria de dígitos y letras minúsculas ASCII).
Una cadena que contiene un diccionario de sesión codificado y serializado.
Una fecha designando cuando la sesión expira.
Las sesiones expiradas no están disponibles para el usuario, sin embargo, pueden estar almacenadas en la base de datos hasta que se ejecute el comando administrativo clearsessions.
Devuelve una clase de almacén de sesión para ser utilizada con este modelo de sesión.
Regresa los datos de sesión decodificados.
La descodificación se realiza mediante la clase de almacenamiento de sesión.
También puedes personalizar el administrador del modelo sobrescribiendo BaseSessionManager:
Devuelve el diccionario de sesión dado serializado y codificado como una cadena.
La codificación se realiza mediante la clase de almacenamiento de sesión vinculada a una clase del modelo.
Almacena los datos de sesión para una clave de sesión proporcionada, o elimina la sesión en caso de que los datos estén vacíos.
La personalización de las clases SessionStore se logra sobrescribiendo métodos y propiedades descritas a continuación:
Implementa el almacenamiento de sesión basado en base de datos.
Sobreescribe este método para devolver un modelo de sesión personalizado si lo necesitas.
Devuelve una nueva instancia del objeto del modelo de sesión, que representa el estado actual de la sesión.
Overriding este método proporciona la capacidad de modificar los datos del modelo de sesión antes de que sean guardados en la base de datos.
Implementa una tienda de sesiones con base de datos respaldada por caché.
Un prefijo agregado a una clave de sesión para construir una cadena de clave de caché.
El ejemplo a continuación muestra un motor de sesión basado en la base de datos personalizado que incluye una columna adicional de la base de datos para almacenar el ID de cuenta (lo que proporciona la opción de consultar la base de datos por todas las sesiones activas para una cuenta):
from django.contrib.sessions.backends.db import SessionStore as DBStore
from django.contrib.sessions.base_session import AbstractBaseSession
from django.db import models
class CustomSession(AbstractBaseSession):
account_id = models.IntegerField(null=True, db_index=True)
@classmethod
def get_session_store_class(cls):
return SessionStore
class SessionStore(DBStore):
@classmethod
def get_model_class(cls):
return CustomSession
def create_model_instance(self, data):
obj = super().create_model_instance(data)
try:
account_id = int(data.get("_auth_user_id"))
except (ValueError, TypeError):
account_id = None
obj.account_id = account_id
return obj
Si estás migrando desde la tienda de sesión cached_db incorporada de Django a una personalizada basada en cached_db, debes sobrescribir el prefijo de clave de caché para evitar un conflicto de nombres:
class SessionStore(CachedDBStore):
cache_key_prefix = "mysessions.custom_cached_db_backend"
# ...
El marco de sesiones de Django es enteramente y exclusivamente, basado en cookies. No cae en la cuenta de poner los IDs de sesión en las URL como último recurso, al igual que PHP lo hace. Esta es una decisión de diseño intencional. No solo eso haría que las URLs sean feas, sino que también haría vulnerable tu sitio a la suplantación de ID de sesión mediante el encabezado «Referer».
may 31, 2026