Utilisation des sessions¶
Django prend complètement en charge les sessions anonymes. L’infrastructure des sessions permet de stocker et de récupérer des données arbitraires sur la base « un site-un visiteur ». Les données sont stockées côté serveur ; l’envoi et la réception des cookies sont transparents. Les cookies contiennent un identifiant de session, et non pas les données elles-mêmes (sauf si vous utilisez le moteur basé sur les cookies).
Activation des sessions¶
Les sessions sont implémentées par l’intermédiaire d’un composant middleware.
Pour activer la fonctionnalité des sessions, faites ce qui suit :
Contrôlez que le réglage
MIDDLEWARE
contient bien'django.contrib.sessions.middleware.SessionMiddleware'
. Le fichiersettings.py
créé par défaut pardjango-admin startproject
activeSessionMiddleware
.
Si vous ne souhaitez pas utiliser les sessions, vous pouvez très bien enlever la ligne SessionMiddleware
de MIDDLEWARE
et la ligne 'django.contrib.sessions'
de INSTALLED_APPS
. Cela économisera un peu de travail à Django.
Configuration du moteur de sessions¶
Par défaut, Django stocke les sessions dans la base de données (avec le modèle django.contrib.sessions.models.Session
). Bien que cela puisse être pratique, il est plus rapide dans certaines configurations de stocker les données de sessions ailleurs ; il est donc possible de configurer Django pour stocker les données de sessions sur le système de fichiers ou dans un cache.
Utilisation des sessions en base de données¶
Si vous souhaitez placer le contenu des sessions en base de données, vous devez ajouter 'django.contrib.sessions'
dans le réglage INSTALLED_APPS
.
Après avoir configuré votre installation, lancez manage.py migrate
pour installer l’unique table de base de données qui stocke les données des sessions.
Utilisation des sessions en cache¶
Pour de meilleures performances, il est recommandé d’utiliser le moteur de sessions basé sur le cache.
Pour stocker les données de sessions en utilisant le système de cache de Django, il s’agit d’abord de s’assurer que le cache est configuré ; voir la documentation du cache pour plus de détails.
Avertissement
Les données de sessions ne devraient être stockées en cache que quand le moteur de cache Memcached ou Redis est utilisé. Le moteur de cache en mémoire locale ne retient pas assez longtemps les données pour qu’il représente un bon choix, et il est plus rapide d’utiliser directement le moteur de sessions basé sur des fichiers ou sur la base de données que de faire transiter le tout par les moteurs de cache basés sur des fichiers ou sur la base de données. De plus, le moteur de cache en mémoire locale ne gère PAS correctement le mode multi-processus et n’est donc probablement pas un bon choix dans un environnement de production.
Si plusieurs caches sont définis dans CACHES
, Django utilise le cache par défaut. Pour utiliser un autre cache, définissez SESSION_CACHE_ALIAS
avec le nom de ce cache.
Une fois que votre cache est configuré, vous devez choisir entre un cache basé sur la base de données et un cache non persistant.
Le moteur basé sur la base de données avec cache (cached_db`) utilise un cache à écriture immédiate – les écritures de sessions sont appliquées à la fois à la base de données et au cache, dans cet ordre. Si l’écriture dans le cache échoue, l’exception est interceptée et journalisée via le journaliseur des sessions, pour éviter de faire échouer l’opération d’écriture qui s’est fait correctement en base de données.
Le traitement et la journalisation des exceptions au moment d’écrire dans le cache ont été ajoutés.
Les lectures de sessions utilisent d’abord le cache, puis la base de données si les données recherchées ont été évincées du cache. Pour utiliser ce moteur, définissez SESSION_ENGINE
à "django.contrib.sessions.backends.cached_db"
et suivez les instructions de configuration dans utilisation des sessions stockées en base de données.
Le moteur de sessions en cache (cache
) stocke les données des sessions uniquement dans le cache. C’est plus rapide car on évite la persistance en base de données, mais il faut prendre en compte ce qui arrive quand les données du cache sont purgées. La purge peut arriver si le cache est plein ou si le serveur de cache est redémarré, et cela va provoquer la perte des données de sessions, y compris pour les utilisateurs se déconnectant. Pour utiliser ce moteur, définissez SESSION_ENGINE
à "django.contrib.sessions.backends.cache"
.
Le moteur en cache peut être rendu persistant en utilisant un cache persistant, tel que Redis avec une configuration appropriée. Mais tant que le cache n’est pas complètement configuré avec la persistance nécessaire, préférez le moteur basé sur la base de données avec cache. Cela évite des cas limites provoqués par un stockage de données non fiable en production.
Utilisation des sessions basées sur des fichiers¶
Pour utiliser les sessions basées sur des fichiers, définissez le réglage SESSION_ENGINE
à "django.contrib.sessions.backends.file"
.
Il peut aussi être souhaitable de définir le réglage SESSION_FILE_PATH
(dont la valeur par défaut est le résultat de tempfile.gettempdir()
, généralement /tmp
) pour contrôler l’emplacement où Django stocke les fichiers de sessions. Vérifiez que le serveur web dispose des permissions en lecture et écriture à cet endroit.
Utilisation des sessions dans les vues¶
Lorsque SessionMiddleware
est actif, chaque objet HttpRequest
, le premier paramètre de toute fonction vue de Django, possède un attribut session
qui est un objet de type dictionnaire.
Vous pouvez lire et écrire dans request.session
à n’importe quel moment dans votre vue. Vous pouvez le modifier plusieurs fois.
- class backends.base.SessionBase¶
C’est la classe de base pour tous les objets session. Elle possède les méthodes de dictionnaire standard suivantes :
- __getitem__(key)¶
Exemple :
- __setitem__(key, value)¶
Exemple :
request.session['fav_color'] = 'blue'
- __delitem__(key)¶
Exemple :
del request.session['fav_color']
. Si la clé indiquée ne se trouve pas déjà dans l’objet session, une exceptionKeyError
est levée.
- __contains__(key)¶
Exemple :
'fav_color' in request.session
- get(key, default=None)¶
- aget(key, default=None)¶
Version asynchrone:
aget()
Exemple :
fav_color = request.session.get('fav_color', 'red')
Changed in Django 5.1:La fonction
aget()
a été ajoutée.
- aset(key, value)¶
- New in Django 5.1.
Exemple :
await request.session.aset('fav_color', 'red')
- update(dict)¶
- aupdate(dict)¶
Version asynchrone:
aupdate()
Exemple :
request.session.update({'fav_color': 'red'})
Changed in Django 5.1:La fonction
aupdate()
a été ajoutée.
- pop(key, default=__not_given)¶
- apop(key, default=__not_given)¶
Version asynchrone:
apop()
Exemple :
fav_color = request.session.pop('fav_color', 'blue')
Changed in Django 5.1:La fonction
apop()
a été ajoutée.
- keys()¶
- akeys()¶
Version asynchrone:
akeys()
Changed in Django 5.1:La fonction
akeys()
a été ajoutée.
- values()¶
- avalues()¶
Version asynchrone:
avalues()
Changed in Django 5.1:La fonction
avalues()
a été ajoutée.
- has_key(key)¶
- ahas_key(key)¶
Version asynchrone:
ahas_key()
Changed in Django 5.1:La fonction
ahas_key()
a été ajoutée.
- items()¶
- aitems()¶
Version asynchrone:
aitems()
Changed in Django 5.1:La fonction
aitems()
a été ajoutée.
- setdefault()¶
- asetdefault()¶
Version asynchrone:
asetdefault()
Changed in Django 5.1:La fonction
asetdefault()
a été ajoutée.
- clear()¶
Elle possède aussi ces méthodes :
- flush()¶
- aflush()¶
Version asynchrone:
aflush()
Supprime les données de la session actuelle et supprime le cookie de session. C’est utile pour s’assurer que les données de session précédentes ne puissent plus être relues par le navigateur de l’utilisateur (par exemple, c’est ce que fait
django.contrib.auth.logout()
).Changed in Django 5.1:La fonction
aflush()
a été ajoutée.
- set_test_cookie()¶
- aset_test_cookie()¶
Version asynchrone :
aset_test_cookie()
Crée un cookie de test pour déterminer si le navigateur de l’utilisateur prend en charge les cookies. En raison du fonctionnement des cookies, vous ne pourrez pas déterminer cela avant la prochaine requête de l’utilisateur. Consultez Génération de cookies de test ci-dessous pour obtenir plus d’informations.
Changed in Django 5.1:La fonction
aset_test_cookie()
a été ajoutée.
- test_cookie_worked()¶
- atest_cookie_worked()¶
Version asynchrone :
atest_cookie_worked()
Renvoie
True
ouFalse
, selon que le navigateur de l’utilisateur a accepté le cookie de test ou non. En raison du fonctionnement des cookies, vous aurez dû appelerset_test_cookie()
ouaset_test_cookie()
sur une requête de page précédente. Consultez Génération de cookies de test ci-dessous pour obtenir plus d’informations.Changed in Django 5.1:La fonction
atest_cookie_worked()
a été ajoutée.
- delete_test_cookie()¶
- adelete_test_cookie()¶
Version asynchrone :
adelete_test_cookie()
Supprime le cookie de test. Utilisé pour faire le ménage derrière soi.
Changed in Django 5.1:La fonction
adelete_test_cookie()
a été ajoutée.
- get_session_cookie_age()¶
Renvoie la valeur du réglage
SESSION_COOKIE_AGE
. Ceci peut être surchargé dans un moteur de session personnalisé.
- set_expiry(value)¶
- aset_expiry(value)¶
Version asynchrone:
aset_expiry()
Définit la durée d’expiration de la session. Il est possible de passer plusieurs valeurs différentes :
Si
value
est un nombre entier, la session va expirer après ce nombre de secondes d’inactivité. Par exemple, l’appel derequest.session.set_expiry(300)
va provoquer l’expiration de la session dans 5 minutes.Si
value
est un objetdatetime
(date/heure) ortimedelta
(différence de temps), la session va expirer au moment précis correspondant à la valeur transmise.Si la
value
est0
, le cookie de session de l’utilisateur va expirer au moment où celui-ci ferme son navigateur web.Si
value
estNone
, la session se fie à nouveau à la politique d’expiration globale des sessions.
La lecture d’une session n’est pas considérée comme une activité en regard de la notion d’expiration. L’expiration de la session est calculée à partir du moment de la dernière modification de la session.
Changed in Django 5.1:La fonction
aset_expiry()
a été ajoutée.
- get_expiry_age()¶
- aget_expiry_age()¶
Version asynchrone:
aget_expiry_age()
Renvoie le nombre de secondes restant jusqu’à l’expiration de la session. Pour les sessions sans expiration particulière (ou celles qui expirent à la fermeture du navigateur), cette valeur sera égale à
SESSION_COOKIE_AGE
.Cette fonction accepte deux paramètres nommés facultatifs :
modification
: dernière modification de la session, comme objetdatetime
. Par défaut, c’est l’heure actuelle.expiry
: information d’expiration de la session, comme objetdatetime
, valeurint
(en secondes) ouNone
. Par défaut, cette valeur est égale à celle stockée dans la session parset_expiry()
/aset_expiry()
, le cas échéant, sinonNone
.
Note
Cette méthode est utilisée par les moteurs de session pour déterminer l’âge d’expiration de session en secondes au moment d’enregistrer la session. Elle n’est pas vraiment appropriée pour des utilisations en dehors de ce contexte.
En particulier, bien qu’il soit possible de déterminer la durée de vie restante d’une session juste au moment où vous avez la valeur
modification
correcte et queexpiry
est défini comme objetdatetime
, dans le cas où vous disposez de la valeurmodification
, il est plus direct de calculer l’expiration à la mainexpires_at = modification + timedelta(seconds=settings.SESSION_COOKIE_AGE)
Changed in Django 5.1:La fonction
aget_expiry_age()
a été ajoutée.
- get_expiry_date()¶
- aget_expiry_date()¶
Version asynchrone:
aget_expiry_date()
Renvoie la date à laquelle la session expire. Pour les sessions sans expiration particulière (ou celles qui expirent à la fermeture du navigateur), cette valeur sera égale à
SESSION_COOKIE_AGE
secondes à partir de maintenant.Cette fonction accepte les mêmes paramètres mots-clés que
get_expiry_age()
, et les mêmes notes sur son utilisation s’appliquent.Changed in Django 5.1:La fonction
aget_expiry_date()
a été ajoutée.
- get_expire_at_browser_close()¶
- aget_expire_at_browser_close()¶
Version asynchrone:
aget_expire_at_browser_close()
Renvoie
True
ouFalse
selon que le cookie de session utilisateur expire au moment de la fermeture du navigateur web de l’utilisateur ou non.Changed in Django 5.1:La fonction
aget_expire_at_browser_close()
a été ajoutée.
- clear_expired()¶
- aclear_expired()¶
Version asynchrone:
aclear_expired()
Supprime les sessions expirées du stockage des sessions. Cette méthode de classe est appelée par
clearsessions
.Changed in Django 5.1:La fonction
aclear_expired()
a été ajoutée.
- cycle_key()¶
- acycle_key()¶
Version asynchrone:
acycle_key()
Crée une nouvelle clé de session tout en conservant les données de session actuelles.
django.contrib.auth.login()
appelle cette méthode pour lutter contre les attaques par fixation de session.Changed in Django 5.1:La fonction
acycle_key()
a été ajoutée.
Sérialisation des sessions¶
Par défaut, Django sérialise les données de session en JSON. Vous pouvez utiliser le réglage SESSION_SERIALIZER
pour personnaliser le format de sérialisation de session. Même en considérant les limites décrites dans Écriture de son propre sérialiseur, nous recommandons fortement d’en rester à la sérialisation JSON, d’autant plus si vous utilisez le moteur cookie.
Par exemple, voici un scénario d’attaque si vous utilisez pickle
pour sérialiser les données de session. Si vous utilisez le moteur de session basé sur des cookies signés et que la clé SECRET_KEY
(ou une autre clé de SECRET_KEY_FALLBACKS
) est connue d’un attaquant (il n’y a aucune vulnérabilité connue dans Django qui divulguerait cette information), cet attaquant pourrait insérer une chaîne dans la session, ce qui pourrait conduire, au moment de la désérialisation (« unpickling »), à une exécution de code arbitraire sur le serveur. La technique pour faire cela est simple et aisément disponible sur Internet. Même si le stockage de sessions par cookies signe les données de session pour empêcher leur falsification, une divulgation de la clé SECRET_KEY
crée immédiatement une vulnérabilité d’exécution de code à distance.
Sérialiseurs intégrés¶
- class serializers.JSONSerializer¶
Un adaptateur du sérialiseur JSON provenant de
django.core.signing
. Ne peut sérialiser que des types de données simples.De plus, comme JSON ne gère que des clés textuelles, il faut savoir que des clés non textuelles dans
request.session
ne fonctionneront pas comme prévu :>>> # initial assignment >>> request.session[0] = "bar" >>> # subsequent requests following serialization & deserialization >>> # of session data >>> request.session[0] # KeyError >>> request.session["0"] 'bar'
De même, les données qui ne peuvent pas être codées en JSON telles que des octets non UTF-8 comme
'\xd9'
(ce qui produitUnicodeDecodeError
), ne peuvent pas être stockées.Consultez la section Écriture de son propre sérialiseur pour plus de détails sur les limites de la sérialisation JSON.
Écriture de son propre sérialiseur¶
Notez que JSONSerializer
ne sait pas traiter n’importe quel type de donnée Python. Comme c’est souvent le cas, il faut contrebalancer commodité et sécurité. Si vous souhaitez stocker des types de données plus spécialisées comme datetime
ou Decimal
dans des sessions en JSON, vous devrez écrire votre propre sérialiseur (ou convertir ces valeurs en objets sérialisables en JSON avant de les stocker dans request.session
). Bien que la sérialisation de telles valeurs soit relativement directe à réaliser (DjangoJSONEncoder
donne des pistes), l’écriture d’un décodeur qui puisse reconstruire la valeur initiale de manière fiable est plus délicate. Par exemple, vous risquez de créer un objet datetime
pour ce qui était en fait une chaîne dont le format ressemblait à celui que vous avez choisi pour représenter les objets datetime
.
Une classe de sérialisation doit implémenter deux méthodes, dumps(self, obj)
et loads(self, data)
, pour respectivement sérialiser et désérialiser le dictionnaire des données de session.
Lignes directrices des objets sessions¶
Utilisez des chaînes Python normales comme clés de dictionnaire pour
request.session
. Il s’agit plus d’une convention que d’une règle stricte.Les clés de dictionnaire de session commençant par un soulignement sont réservés pour l’usage interne de Django.
Ne surchargez pas
request.session
avec un nouvel objet et n’accédez pas ou ne modifiez pas ses attributs. Utilisez-le comme un dictionnaire Python.
Exemples¶
Cette vue très simple définit une variable has_commented
à True
après qu’un utilisateur a soumis un commentaire. Elle n’autorise pas plus d’un commentaire par utilisateur :
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!")
Cette vue très simple connecte un « membre » du site :
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.")
…et celle-ci déconnecte un membre, compte tenu de l’exemple login()
ci-dessus :
def logout(request):
try:
del request.session["member_id"]
except KeyError:
pass
return HttpResponse("You're logged out.")
La fonction standard django.contrib.auth.logout()
fait en réalité un peu plus que cela pour empêcher des divulgations de données fortuites. Elle appelle la méthode flush()
de request.session
. Nous utilisons cet exemple comme démonstration du fonctionnement des objets sessions, il ne faut pas le considérer comme une implémentation complète de logout()
.
Utilisation des sessions en dehors des vues¶
Note
Les exemples de cette section importent directement l’objet SessionStore
à partir du moteur django.contrib.sessions.backends.db
. Dans votre propre code, il est préférable d’importer SessionStore
à partir du moteur de sessions désigné par SESSION_ENGINE
, comme ci-dessous :
>>> from importlib import import_module
>>> from django.conf import settings
>>> SessionStore = import_module(settings.SESSION_ENGINE).SessionStore
Une API est disponible pour manipuler les données de sessions en dehors des vues :
>>> 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 conçue pour créer une nouvelle session (c’est-à-dire qui n’est pas chargée du stockage de session et avec session_key=None
). save()
est conçue pour enregistrer une session existante (c’est-à-dire qui est chargée du stockage de session). Il est aussi possible d’appeler save()
pour une nouvelle session, mais avec un petit risque de générer une clé de session qui entre en conflit avec une autre. create()
appelle save()
et boucle jusqu’à ce qu’une clé session_key
inutilisée soit produite.
Si vous utilisez le moteur django.contrib.sessions.backends.db
, chaque session est un modèle Django normal. Le modèle Session
est défini dans django/contrib/sessions/models.py. Comme c’est un modèle normal, vous pouvez accéder aux sessions en utilisant l’API habituelle de base de données 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)
Notez que vous devrez appeler get_decoded()
pour obtenir le dictionnaire de session. Cela est nécessaire car le dictionnaire est stocké dans un format codé :
>>> s.session_data
'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
>>> s.get_decoded()
{'user_id': 42}
Enregistrement des sessions¶
Par défaut, Django n’enregistre la session dans la base de données qu’au moment où la session a été modifiée, c’est-à-dire qu’au moins une des valeurs de son dictionnaire a été définie ou supprimée :
# 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"
Dans le dernier cas de l’exemple ci-dessus, nous pouvons indiquer explicitement à l’objet session qu’il a été modifié en définissant son attribut modified
:
request.session.modified = True
Pour modifier ce comportement par défaut, définissez le réglage SESSION_SAVE_EVERY_REQUEST
à True
. Dans ce cas, Django enregistre la session dans la base de données lors de chaque requête.
Notez que le cookie de session n’est envoyé que lorsqu’une session a été créée ou modifiée. Si SESSION_SAVE_EVERY_REQUEST
vaut True
, le cookie de session sera envoyé lors de chaque requête.
De même, la partie expires
d’un cookie de session est mis à jour chaque fois que le cookie de session est envoyé.
La session n’est pas enregistrée si le code de statut de la réponse est 500.
Expiration ou persistance des sessions¶
Le réglage SESSION_EXPIRE_AT_BROWSER_CLOSE
permet de contrôler le type des sessions utilisées par l’infrastructure des sessions, soit les sessions expirant à la fermeture du navigateur ou les sessions persistantes.
Par défaut, SESSION_EXPIRE_AT_BROWSER_CLOSE
est défini à False
, ce qui signifie que les cookies de session seront stockés dans les navigateurs des utilisateurs pour une durée de SESSION_COOKIE_AGE
. Utilisé quand on ne souhaite pas que les utilisateurs doivent se connecter chaque fois qu’ils ouvrent leur navigateur.
Si SESSION_EXPIRE_AT_BROWSER_CLOSE
est défini à True
, Django utilise des cookies expirant à la fermeture du navigateur. Utilisé quand on souhaite que les utilisateurs doivent se connecter chaque fois qu’ils ouvrent leur navigateur.
Ce réglage est une valeur par défaut globale et peut être surchargé au niveau de chaque session en appelant explicitement la méthode set_expiry()
de request.session
comme décrit ci-dessus dans utilisation des sessions dans les vues.
Note
Certains navigateurs (Chrome, par exemple) peuvent être réglés afin de ne pas fermer les sessions de navigation entre fermeture et réouverture du navigateur. Dans certains cas, cela peut interférer avec le réglage SESSION_EXPIRE_AT_BROWSER_CLOSE
et empêcher les sessions d’expirer à la fermeture du navigateur. Il est important de le savoir lors des tests d’applications Django qui ont le réglage SESSION_EXPIRE_AT_BROWSER_CLOSE
actif.
Effacement du stockage des sessions¶
Au fur et à mesure que des utilisateurs créent de nouvelles sessions sur votre site Web, les données de sessions s’accumulent dans votre stockage de sessions. Si vous utilisez le moteur en base de données, la table de base de données django_session
prend du volume. Si vous utilisez le moteur basé sur des fichiers, le nombre des fichiers dans le répertoire temporaire va augmenter constamment.
Pour comprendre ce problème, examinons ce qui se passe avec le moteur en base de données. Lorsqu’un utilisateur se connecte, Django ajoute un enregistrement dans la table django_session
. Il met à jour cet enregistrement chaque fois que les données de la session sont modifiées. Si l’utilisateur se déconnecte explicitement, Django efface l’enregistrement. Mais si l’utilisateur ne le fait pas, l’enregistrement n’est jamais effacé. Le principe est identique avec le moteur basé sur les fichiers.
Django ne fournit pas de système automatique d’effacement des sessions expirées. C’est donc à vous de le faire à intervalle régulier. Django met à disposition une commande de gestion de nettoyage dans ce but : clearsessions
. Il est recommandé de lancer cette commande régulièrement, par exemple dans une tâche « cron » journalière.
Notez que le moteur basé sur le cache n’est pas sujet à ce problème, car les caches suppriment automatiquement les données obsolètes. Pareil pour le moteur basé sur les cookies, car les données de sessions sont stockées par les navigateurs des utilisateurs.
Réglages¶
Quelques réglages Django permettent de contrôler le comportement des sessions :
Sécurité des sessions¶
Les sous-domaines d’un site peuvent définir des cookies pour le client valables pour tout le domaine. Cela rend possible les attaques par fixation de session si des cookies peuvent être créés par des sous-domaines qui ne sont pas sous contrôle de personnes de confiance.
Par exemple, un attaquant pourrait se connecter à good.example.com
et obtenir une session valable pour son compte. Si l’attaquant contrôle bad.example.com
, il peut l’utiliser pour vous envoyer sa clé de session puisqu’un sous-domaine a le droit de définir des cookies pour *.example.com
. Lorsque vous visitez good.example.com
, vous serez connecté sous le compte de l’attaquant et vous pourriez saisir involontairement des données personnelles sensibles (par ex. des données de carte de crédit) enregistrées dans le compte de l’attaquant.
Une autre attaque possible apparaît dans le cas où good.example.com
définit son réglage SESSION_COOKIE_DOMAIN
à "example.com"
, ce qui pourrait avoir comme conséquence d’envoyer les cookies de session à bad.example.com
.
Détails techniques¶
Le dictionnaire de session accepte toute valeur sérialisable en
json
quand on utiliseJSONSerializer
.Les données des sessions sont stockées dans une table de base de données nommée
django_session
.Django n’envoie un cookie qu’en cas de nécessité. Si vous ne définissez pas de données de session, le cookie de session ne sera pas envoyé.
L’objet SessionStore
¶
Lorsque Django manipule les sessions en interne, il emploie un objet de stockage de session provenant du moteur de sessions correspondant. Par convention, la classe d’objet de stockage de session est appelée SessionStore
et se trouve dans le module désigné par SESSION_ENGINE
.
Toutes les sous-classes de SessionStore
disponibles dans Django implémentent les méthodes de manipulation de données suivantes :
exists()
create()
save()
delete()
load()
Une interface asynchrone de ces méthodes est fournie en les enveloppant dans sync_to_async()
. Elles peuvent être implémentées directement si une implémentation nativement asynchrone est disponible :
aexists()
acreate()
asave()
adelete()
aload()
Dans l’optique de créer un moteur de sessions personnalisé ou d’en adapter un existant, vous pouvez créer une nouvelle classe héritant de SessionBase
ou de toute autre classe SessionStore
existante.
Il est possible d’étendre les moteurs de sessions existants, mais pour les moteurs se basant sur une base de données, cela exige généralement un peu plus de travail (lisez la section suivante pour plus de détails).
Les méthodes aexists()
, acreate()
, asave()
, adelete()
, aload()
et aclear_expired()
ont été ajoutées.
Extension des moteurs de sessions s’appuyant sur une base de données¶
La création d’un moteur de sessions personnalisé s’appuyant sur une base de données en se basant sur ceux qui sont inclus dans Django (c’est-à-dire db
et cached_db
) peut se faire en héritant de AbstractBaseSession
et de l’une des classes SessionStore
.
AbstractBaseSession
et BaseSessionManager
peuvent être importés à partir de django.contrib.sessions.base_session
afin qu’ils puissent être importés sans devoir inclure django.contrib.sessions
dans INSTALLED_APPS
.
- class base_session.AbstractBaseSession¶
Le modèle abstrait de base d’une session.
- session_key¶
La clé primaire. Le champ lui-même peut contenir jusqu’à 40 caractères. L’implémentation actuelle génère une chaîne de 32 caractères (une séquence aléatoire de chiffres et de lettre ASCII minuscules).
- session_data¶
Une chaîne contenant un dictionnaire de session codé et sérialisé.
- expire_date¶
Une date/heure indiquant la date d’expiration de la session.
Les sessions qui ont expiré ne sont plus accessibles aux utilisateurs ; elles peuvent tout de même rester stockées dans la base de données jusqu’au lancement de la commande d’administration
clearsessions
.
- classmethod get_session_store_class()¶
Renvoie une classe de stockage de session à utiliser avec ce modèle de session.
- get_decoded()¶
Renvoie les données de session décodées.
Le décodage est effectué par la classe de stockage de session.
Vous pouvez aussi personnaliser le gestionnaire du modèle en héritant de BaseSessionManager
:
- class base_session.BaseSessionManager¶
- encode(session_dict)¶
Renvoie le dictionnaire de session indiqué sous forme de chaîne codée et sérialisée.
Le codage est effectué par la classe de stockage de session en lien à la classe de modèle.
- save(session_key, session_dict, expire_date)¶
Enregistre les données de session correspondant à la clé de session indiquée ou supprimer la session dans le cas où les données sont vides.
La personnalisation des classes SessionStore
se fait en surchargeant les méthodes et les propriétés décrites ci-après :
- class backends.db.SessionStore¶
Implémentation du stockage de session s’appuyant sur une base de données.
- classmethod get_model_class()¶
Surchargez cette méthode afin de renvoyer un modèle de session personnalisé en cas de besoin.
- create_model_instance(data)¶
Renvoie une nouvelle instance d’objet modèle de session, qui représente l’état actuel de la session.
En surchargeant cette méthode, on peut modifier les données du modèle de session avant qu’elles ne soient enregistrées dans la base de données.
- class backends.cached_db.SessionStore¶
Implémentation du stockage de session s’appuyant sur une base de données et du cache.
- cache_key_prefix¶
Un préfixe ajouté à une clé de session pour construire une chaîne de clé de cache.
Exemple¶
L’exemple ci-dessous montre un moteur de session personnalisé s’appuyant sur une base de données, incluant une colonne de base de données supplémentaire pour stocker un identifiant de compte (et ainsi fournissant une option pour interroger la base de données pour toutes les sessions actives d’un compte) :
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 vous faites une migration à partir du stockage de sessions cached_db
intégré à Django vers un stockage personnalisé basé sur cached_db
, il est conseillé de surcharger le préfixe de clé de cache afin d’éviter d’éventuels conflits d’espace de noms :
class SessionStore(CachedDBStore):
cache_key_prefix = "mysessions.custom_cached_db_backend"
# ...
Identifiants de session dans les URL¶
L’infrastructure des sessions de Django est complètement et uniquement basé sur les cookies. Il ne se rabat pas sur le système des identifiants de session dans les URL comme le fait PHP. C’est une décision conceptuelle volontaire. Cette technique défigure les URL et rend votre site vulnérable aux vols d’identifiants de session par l’intermédiaire de l’en-tête « Referer ».