• en
  • Language: fr

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_CLASSES 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_CLASSES 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 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.

Après avoir configuré le cache, il vous reste deux possibilités pour stocker les données en cache :

  • Dé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.

Changed in Django 1.7:

Avant la version 1.7, le moteur cached_db utilisait toujours le cache default plutôt que le contenu de SESSION_CACHE_ALIAS.

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 exception KeyError est levée.

__contains__(key)

Exemple : 'fav_color' in request.session

get(key, default=None)

Exemple : fav_color = request.session.get('fav_color', 'red')

pop(key)

Exemple : fav_color = request.session.pop('fav_color')

keys()
items()
setdefault()
clear()

Elle possède aussi ces méthodes :

flush()

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 1.8:

La suppression du cookie de session est un nouveau comportement de Django 1.8. Précédemment, le comportement était de régénérer la valeur de clé de session qui était renvoyée à l’utilisateur dans le 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.

Renvoie 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.

set_expiry(value)

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 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.

get_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 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.

get_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().

get_expire_at_browser_close()

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.

clear_expired()

Supprime les sessions expirées du stockage des sessions. Cette méthode de classe est appelée par clearsessions.

cycle_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.

Sérialisation des sessions

Avant la version 1.6, Django utilisait par défaut la méthode pickle pour sérialiser les données de session avant de les stocker dans le moteur. 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.

Cette attaque peut être contrée en sérialisant les données de session en JSON plutôt qu’avec pickle. Pour faciliter cela, Django 1.5.3 a introduit un nouveau réglage, SESSION_SERIALIZER, afin de pouvoir personnaliser le format de sérialisation de session. Par rétrocompatiblité, ce réglage contient par défaut django.contrib.sessions.serializers.PickleSerializer dans Django 1.5.x, mais par mesure de renforcement de sécurité, la valeur par défaut a été changée en django.contrib.sessions.serializers.JSONSerializer dans Django 1.6. 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.

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'

Consultez la section Écriture de son propre sérialiseur pour plus de détails sur les limites de la sérialisation JSON.

class serializers.PickleSerializer

Accepte 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.

Écriture de son propre sérialiseur

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 (django.core.serializers.json.DateTimeAwareJSONEncoder 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.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().

Génération de cookies de test

Par commodité, Django fournit un moyen simple de tester si le navigateur de l’utilisateur accepte les cookies. Il suffit d’appeler la méthode set_test_cookie() de request.session dans une vue, et d’appeler test_cookie_worked() dans une des vues suivantes, mais pas dans le même appel de vue.

Cette séparation bizarre entre set_test_cookie() et test_cookie_worked() est nécessaire en raison du fonctionnement des cookies. Lorsque vous définissez un cookie, il n’est en fait pas possible de savoir si le navigateur l’a accepté avant de recevoir la prochaine requête du navigateur.

Il est recommandé d’utiliser delete_test_cookie() pour faire le ménage derrière soi. Faites-le après avoir vérifié que le cookie de test a fonctionné.

Voici un exemple d’utilisation typique :

def login(request):
    if request.method == 'POST':
        if request.session.test_cookie_worked():
            request.session.delete_test_cookie()
            return HttpResponse("You're logged in.")
        else:
            return HttpResponse("Please enable cookies and try again.")
    request.session.set_test_cookie()
    return render_to_response('foo/login_form.html')

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.save()
>>> s.session_key
'2b1189a188b44ad18c35e113ac6ceead'

>>> s = SessionStore(session_key='2b1189a188b44ad18c35e113ac6ceead')
>>> s['last_login']
1376587691

Afin de contrer les attaques par fixation de session, les clés de sessions qui n’existent pas sont régénérées :

>>> from django.contrib.sessions.backends.db import SessionStore
>>> s = SessionStore(session_key='no-such-session-here')
>>> s.save()
>>> s.session_key
'ff882814010ccbc3c870523934fee5a2'

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
>>> 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.

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 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é.

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 ».

Back to Top