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).
\nLes sessions sont implémentées par l’intermédiaire d’un composant middleware.
\nPour activer la fonctionnalité des sessions, faites ce qui suit :
\nContrôlez que le réglage MIDDLEWARE contient bien 'django.contrib.sessions.middleware.SessionMiddleware'. Le fichier settings.py créé par défaut par django-admin startproject active SessionMiddleware.
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.
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.
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.
Pour de meilleures performances, il est recommandé d’utiliser le moteur de sessions basé sur le cache.
\nPour 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.
\n\nSi 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.
Après avoir configuré le cache, il vous reste deux possibilités pour stocker les données en cache :
\nDéfinissez SESSION_ENGINE à "django.contrib.sessions.backends.cache" pour un système de stockage de sessions simple. Les données de session seront stockées directement dans le cache. Cependant, la persistance de ces données n’est pas garantie : les données en cache peuvent être vidées si le cache est rempli ou si le serveur de cache est redémarré.
Pour obtenir des données de sessions à la fois en cache et persistantes, définir SESSION_ENGINE à "django.contrib.sessions.backends.cached_db". Il s’agit là d’un cache à écriture directe, chaque écriture dans le cache sera également écrite en base de données. Les sessions ne sont lues dans la base de données que si elles ne sont pas déjà dans le cache.
Les deux stockages de sessions sont assez rapides, mais le cache simple est le plus rapide car il ne s’occupe pas de persistance. Dans la plupart des cas, le moteur cached_db sera suffisamment rapide, mais si vous avez besoin de performances optimales et qu’il est acceptable pour vous que les données de sessions soient effacées de temps en temps, le moteur cache est fait pour vous.
Si vous utilisez le moteur de session cached_db, vous devrez aussi suivre les instructions de configuration décrites dans Utilisation des sessions en base de données.
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.
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.
C’est la classe de base pour tous les objets session. Elle possède les méthodes de dictionnaire standard suivantes :
\nExemple :
\nExemple : request.session['fav_color'] = 'blue'
Exemple : del request.session['fav_color']. Si la clé indiquée ne se trouve pas déjà dans l’objet session, une exception KeyError est levée.
Exemple : 'fav_color' in request.session
Exemple : fav_color = request.session.get('fav_color', 'red')
Exemple : fav_color = request.session.pop('fav_color', 'blue')
Elle possède aussi ces méthodes :
\nSupprime 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()).
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.
\nRenvoie True ou False, selon que le navigateur de l’utilisateur a accepté le cookie de test ou non. En raison du fonctionnement des cookies, vous aurez dû appeler set_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.
Supprime le cookie de test. Utilisé pour faire le ménage derrière soi.
\nDéfinit la durée d’expiration de la session. Il est possible de passer plusieurs valeurs différentes :
\nSi value est un nombre entier, la session va expirer après ce nombre de secondes d’inactivité. Par exemple, l’appel de request.session.set_expiry(300) va provoquer l’expiration de la session dans 5 minutes.
Si value est un objet datetime ou timedelta, la session va expirer à cette date et heure spécifique. Notez que les valeurs datetime et timedelta ne sont sérialisables que si vous utilisez la sérialisation PickleSerializer.
Si la value est 0, le cookie de session de l’utilisateur va expirer au moment où celui-ci ferme son navigateur Web.
Si value est None, 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.
\nRenvoie 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 :
\nmodification: dernière modification de la session, comme objet datetime. Par défaut, c’est l’heure actuelle.
expiry: information d’expiration de la session, comme objet datetime, valeur int (en secondes) ou None. Par défaut, cette valeur est égale à celle stockée dans la session par set_expiry(), le cas échéant, sinon None.
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().
Renvoie True ou False selon que le cookie de session utilisateur expire au moment de la fermeture du navigateur Web de l’utilisateur ou non.
Supprime les sessions expirées du stockage des sessions. Cette méthode de classe est appelée par clearsessions.
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.
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 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.
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\n>>> request.session[0] = 'bar'\n>>> # subsequent requests following serialization & deserialization\n>>> # of session data\n>>> request.session[0] # KeyError\n>>> request.session['0']\n'bar'\nDe 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 produit UnicodeDecodeError), 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.
\nAccepte n’importe quel objet Python, mais, comme expliqué ci-dessus, peut conduire à des vulnérabilités d’exécution de code à distance si la clé SECRET_KEY est révélée à un attaquant.
Notez qu’au contraire de PickleSerializer, 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 simple à 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.
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.
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):\n if request.session.get('has_commented', False):\n return HttpResponse("You've already commented.")\n c = comments.Comment(comment=new_comment)\n c.save()\n request.session['has_commented'] = True\n return HttpResponse('Thanks for your comment!')\nCette vue très simple connecte un « membre » du site :
\ndef login(request):\n m = Member.objects.get(username=request.POST['username'])\n if m.password == request.POST['password']:\n request.session['member_id'] = m.id\n return HttpResponse("You're logged in.")\n else:\n return HttpResponse("Your username and password didn't match.")\n…et celle-ci déconnecte un membre, compte tenu de l’exemple login() ci-dessus :
def logout(request):\n try:\n del request.session['member_id']\n except KeyError:\n pass\n return HttpResponse("You're logged out.")\nLa 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().
Une API est disponible pour manipuler les données de sessions en dehors des vues :
\n>>> from django.contrib.sessions.backends.db import SessionStore\n>>> s = SessionStore()\n>>> # stored as seconds since epoch since datetimes are not serializable in JSON.\n>>> s['last_login'] = 1376587691\n>>> s.create()\n>>> s.session_key\n'2b1189a188b44ad18c35e113ac6ceead'\n>>> s = SessionStore(session_key='2b1189a188b44ad18c35e113ac6ceead')\n>>> s['last_login']\n1376587691\nSessionStore.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 n’est en fait qu’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\n>>> s = Session.objects.get(pk='2b1189a188b44ad18c35e113ac6ceead')\n>>> s.expire_date\ndatetime.datetime(2005, 8, 20, 13, 35, 12)\nNotez 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\n'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'\n>>> s.get_decoded()\n{'user_id': 42}\nPar 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 :
\n# Session is modified.\nrequest.session['foo'] = 'bar'\n\n# Session is modified.\ndel request.session['foo']\n\n# Session is modified.\nrequest.session['foo'] = {}\n\n# Gotcha: Session is NOT modified, because this alters\n# request.session['foo'] instead of request.session.\nrequest.session['foo']['bar'] = 'baz'\nDans 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\nPour 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.
\nLe 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.
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.
\nQuelques réglages Django permettent de contrôler le comportement des sessions :
\n\nLes 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.
\nPar 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.
Le dictionnaire de session accepte n’importe quelle données sérialisable en json lors de l’utilisation de JSONSerializer ou n’importe quel objet Python sérialisable par pickle en cas d’utilisation de PickleSerializer. Consultez la documentation du module pickle pour plus d’informations.
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é.
SessionStoreLien vers cette rubrique#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 classes SessionStore disponibles dans Django héritent de SessionBase et implémentent des méthodes de manipulation de données, en l’occurrence :
exists()
create()
save()
delete()
load()
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 relativement simple d’étendre la plupart des moteurs de sessions existants, à l’exception des moteurs se basant sur une base de données qui exigent généralement un peu plus de travail (lisez la section suivante pour plus de détails).
\nLa 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.
Le modèle abstrait de base d’une session.
\nLa 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).
\nUne chaîne contenant un dictionnaire de session codé et sérialisé.
\nUne date/heure indiquant la date d’expiration de la session.
\nLes 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.
Renvoie une classe de stockage de session à utiliser avec ce modèle de session.
\nRenvoie les données de session décodées.
\nLe décodage est effectué par la classe de stockage de session.
\nVous pouvez aussi personnaliser le gestionnaire du modèle en héritant de BaseSessionManager:
Renvoie le dictionnaire de session indiqué sous forme de chaîne codée et sérialisée.
\nLe codage est effectué par la classe de stockage de session en lien à la classe de modèle.
\nEnregistre 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.
\nLa personnalisation des classes SessionStore se fait en surchargeant les méthodes et les propriétés décrites ci-après :
Implémentation du stockage de session s’appuyant sur une base de données.
\nSurchargez cette méthode afin de renvoyer un modèle de session personnalisé en cas de besoin.
\nRenvoie une nouvelle instance d’objet modèle de session, qui représente l’état actuel de la session.
\nEn 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.
\nImplémentation du stockage de session s’appuyant sur une base de données et du cache.
\nUn préfixe ajouté à une clé de session pour construire une chaîne de clé de cache.
\nL’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) :
\nfrom django.contrib.sessions.backends.db import SessionStore as DBStore\nfrom django.contrib.sessions.base_session import AbstractBaseSession\nfrom django.db import models\n\nclass CustomSession(AbstractBaseSession):\n account_id = models.IntegerField(null=True, db_index=True)\n\n @classmethod\n def get_session_store_class(cls):\n return SessionStore\n\nclass SessionStore(DBStore):\n @classmethod\n def get_model_class(cls):\n return CustomSession\n\n def create_model_instance(self, data):\n obj = super(SessionStore, self).create_model_instance(data)\n try:\n account_id = int(data.get('_auth_user_id'))\n except (ValueError, TypeError):\n account_id = None\n obj.account_id = account_id\n return obj\nSi 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):\n cache_key_prefix = 'mysessions.custom_cached_db_backend'\n\n # ...\nL’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 ».
\n