Le livre de

Obtenir et paramètrer les Cookies

Lorsque vous aurez à faire à la persistence sous Django, la plupart du temps vous voudrez utiliser les sessions de plus haut niveau ou les frameworks utilisateurs abordés un peu plus loin dans ce chapitre. Cependant, nous ferons une pause et regarderons comment lire et écrire les cookies à un bas niveau. Ceci doit vous aider à comprendre comment le reste des outils utilisés dans ce chapitre fonctionne réellement, et restera utile si vous devez un jour jouer directement avec ces cookies.

Lire les cookies qui sont déjà paramétrés est incroyablement simple. Chaque objet requête possède un objet COOKIES qui se comporte comme un dictionnaire; vous pouvez l’utiliser pour lire n’importe quel cookie que le navigateur a envoyé à la vue:

def show_color(request):
    if "favorite_color" in request.COOKIES:
        return HttpResponse("Your favorite color is %s" % \
            request.COOKIES["favorite_color"])
    else:
        return HttpResponse("You don't have a favorite
        color.")

Écrire des cookies est légèrement plus compliqué. Vous devez utiliser la méthode set_cookie() sur un objet HttpResponse. Voici un exemple qui paramètre le cookie favorite_color selon le paramètre GET:

def set_color(request):
    if "favorite_color" in request.GET:

        # Create an HttpResponse object...
        response = HttpResponse("Your favorite color is now
        %s" % \
            request.GET["favorite_color"])

        # ... and set a cookie on the response
        response.set_cookie("favorite_color", request.GET["favorite_color"])

        return response

    else:
        return HttpResponse("You didn't give a favorite
        color.")

Vous pouvez aussi transmettre un nombre d’arguments optionnels à response.set_cookie() qui contrôle l’aspect du cookie, comme le montre le tableau 12-1.

Table 12-1: options de cookie

Les bienfaits des cookies

Vous avez peut être remarquez quelques problèmes potentiels avec la façon dont fonctionnent les cookies. Détaillons ceux parmis les plus importants:

• le stockage des cookies est essentiellement volontaire; les navigateurs ne garantissent rien. En fait, tous les navigateurs proposent aux utilisateurs une politique pour accepter les cookies. Si vous voulez voire combien les cookies sont vitaux pour le web, essayez d’activer l’option «demander confirmation avant d’accepter les cookies».

  En dépis de leur usage quasi universel, les cookies se définnisent encore par leur manque de fiabilité. Ceci signifie que les développeurs doivent vérifier que l’utilisateur accepte les cookies avant de se baser sur ceux-ci.

  Plus important, vous ne devez jamais stocker des données importantes dans des cookies. Le web est plein d’histoires horribles de développeurs qui ont perdu des données stockées dans les cookies du navigateur et qui ont vu ces données purgées par le navigateur, pour une raison ou pour une autre.

• Cookies (en particulier ceux n’étant pas transmis par HTTPS) ne sont pas sûres. Puisque les données HTTP sont envoyé en texte, les cookies sont extremement vulnérables aux attaques de type sniffeuses. Ce faisant, un attaquant sniffant les paquets peut intercepter un cookie et le lire. Cela signifie que vous ne devez jamais stocker des informations sensibles dans un cookie.

  Il existe même une attaque encore plus incidieuse, connue sous le nom de man-in-the-middle, où l’attaquant intercepte un cookie et l’utilise pour se substituer à un autre utilisateur. Le chapitre 19 aborde les attaques de cette nature en profondeur, et les façon de s’en prévenir.

• Même les cookies provenant du destinataire prévu ne sont pas sûres. La plupart des navigateurs fournissent un moyen simple pour éditer le contenu individuel des cookies, sans compter sur les utilisateurs avertis qui peuvent toujours utiliser des outils tel que mechanize (http://wwwsearch.sourceforge.net/mechanize/) pour construire des requêtes HTTP à la main.

  Vous ne pouvez donc pas stocker des données dans les cookies qui peuvent être falsifiés. L’erreur canonique de ce scénario est de stocker quelque chose comme IsLoggedIn=1 dans un cookie lorsqu’un utilisateur se connecte. Vous seriez surpris par le nombre de sites qui font des erreurs de cette nature; une seconde est nécessaire pour tromper le système de sécurité de ces sites .

Activer les sessions

Les sessions sont implémentées via un morceau de middleware (voir le chapitre 15) ainsi que via un modèle Django. Pour activer les sessions, vous devrez suivre les étapes suivantes:

1. Éditez votre paramètre MIDDLEWARE_CLASSES et assurez vous que MIDDLEWARE_CLASSES contient 'django.contrib.sessions.middleware.SessionMiddleware'.
2. Assurez vous que 'django.contrib.sessions' soit présent dans votre paramètre INSTALLED_APPS (et lancez manage.py syncdb si vous devez l’ajouter).

Le squelette de paramètres crée par défaut avec la commande startproject possède déjà deux morceaux d’installés, aussi à moins que vous ne les ayez enlevé, vous n’aurez probablement rien à modifier pour faire fonctionner les sessions.

Si vous ne désirez pas utiliser les sessions, vous devrez enlever la ligne SessionMiddleware de MIDDLEWARE_CLASSES et la ligne 'django.contrib.sessions' de vos INSTALLED_APPS. Ceci ne vous épargnera qu’un peu de surcharge, mais chaque petit morceau compte.

Utiliser les sessions dans les vues

Lorsque SessionMiddleware est activé, chaque objet HttpRequest - le premier argument de chaque fonction vue de Django - aura un attribut de session, qui est un objet assimilable à un dictionnaire. Vous pouvez le lire et écrire dedans de la même manière qu’avec un dictionnaire normal. Par exemple, dans une vue vous pouvez faire des choses comme cela:

# Set a session value:
request.session["fav_color"] = "blue"

# Get a session value -- this could be called in a different view,
# or many requests later (or both):
fav_color = request.session["fav_color"]

# Clear an item from the session:
del request.session["fav_color"]

# Check if the session has a given key:
if "fav_color" in request.session:
    ...

Vous pouvez aussi utiliser d’autre méthode de mapping telles que keys() et items() sur request.session.

Il y a quelques règles simples pour utiliser les sessions Django efficacement:

• Utiliser des chaînes Python tels que les clefs de dictionnaire sur request.session (par opposition aux entiers, objets, etc.). Ceci est plus une convention qu’une règle intangible, mais il est préférable de la suivre.
• les clefs du dictionnaire de session commencant par un soulignement sont réservé pour l’usage interne de Django. En pratique, le framework n’utilise seulement qu’un petit nombre de variables de sessions préfixées par un soulignement, mais à moins de toutes les connaîtres (et de vous abliger à coller à tout changement apporté à Django lui-même), rester éloigné de tels préfixes vous évitera que Django interfère avec votre application.
• Ne remplacez pas request.session par un nouvel objet, et n’accédez pas ou ne déclarez pas ses attributs. Utilisez le comme un dictionnaire Python.

Regardons à présent quelques exemples. Cette vue simpliste fixe une variable has_commented à True après qu’un utilisateur ait posté un commentaire. C’est une manière simple (mais pas particulièrement sûre) d’éviter qu’un utilisateur poste plus d’un commentaire:

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 simpliste connecte un «membre» du site:

def login(request):
   try:
       m =
       Member.objects.get(username__exact=request.POST['username'])
       if m.password == request.POST['password']:
           request.session['member_id'] = m.id
           return HttpResponse("You're logged in.")
   except Member.DoesNotExist:
       return HttpResponse("Your username and password
       didn't match.")

et celle-ci déconnecte un membre, en accord avec login():

def logout(request):
    try:
        del request.session['member_id']
    except KeyError:
        pass
    return HttpResponse("You're logged out.")

Setting Test Cookies

Comme nous venons de le dire, vous ne pouvez par compter sur le navigateur pour accepter les cookies. Aussi, par commodité, Django fourni un moyen simple de tester si le navigateur de l’utilisateur accepte les cookies. Vous devez simplement appeler request.session.set_test_cookie() dans une vue, puis vérifier request.session.test_cookie_worked() dans une vue postérieure - pas dans le même appel de vue.

Cette coupure maladroite entre set_test_cookie() et test_cookie_worked() est rendue nécessaire par la façon dont fonctionne les cookies. Lorsque vous fixez un cookie, vous ne pouvez en fait dire si le navigateur l’a accepté avant de recevoir la prochaine requêtei de ce navigateur.

C’est une bonne pratique d’utiliser delete_test_cookie() pour nettoyer derrière vous. Faîtes cela après avoir vérifié que le cookie de test a fonctionné.

Voici un exemple typique d’utilisation:

def login(request):

    # If we submitted the form...
    if request.method == 'POST':

        # Check that the test cookie worked (we set it
        below):
        if request.session.test_cookie_worked():

            # The test cookie worked, so delete it.
            request.session.delete_test_cookie()

            # In practice, we'd need some logic to check
            username/password
            # here, but since this is an example...
            return HttpResponse("You're logged in.")

        # The test cookie failed, so display an error
        message. If this
        # was a real site we'd want to display a friendlier
        message.
        else:
            return HttpResponse("Please enable cookies
            and try again.")

    # If we didn't post, send the test cookie along with the
    login form.
    request.session.set_test_cookie()
    return render_to_response('foo/login_form.html')

Utiliser les sessions en dehors des vues

En interne, chaque session est est simplement un modèle Django normal, défini dans django.contrib.sessions.models. Chaque session est identifiée par un hachage long de plus ou moin 32 caractères aléatoires stocké dans un cookie. Puisque c’est un modèle normal, vous pouvez accéder aux sessions en utilisant l’PI 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)

Vous devrez appeler get_decoded() pour obtenir les données de sessions actuelles. Cela est nécessaire parceque le dictionnaire est stocké dans un format encodé:

>>> s.session_data
'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
>>> s.get_decoded()
{'user_id': 42}

Quand les sessions sont-elles sauvegardées

Par défaut, Django enregistre uniquement en base de données si la session a été modifié - autrement dit, si aucune des valeurs du dictionnaire n’a été assignée ou éffacé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'

Pour changer ce comportement par défaut, placez SESSION_SAVE_EVERY_REQUEST à True. Si SESSION_SAVE_EVERY_REQUEST vaut True, Django enregistrera la session dans la base de données sur chaque requête unique, même s’il n’y a pas eu de changement.

Notez que le cookie de session est envoyé uniquement lorsque une session à été crée ou modifiée. Si SESSION_SAVE_EVERY_REQUEST vaut True, le cookie de session sera envoyé à chaque requête. De façon similaire, la partie expires d’un cookie de session est mise à jour à chaque fois que le cookie de session est envoyé.

Sessions temporaire vs. sessions persistantes

Vous avez peut-être remarqué que le cookie qu’a envoyé Google contient expires=Sun, 17-Jan-2038 19:14:07 GMT;. Les cookies peuvent optionellement contenir une date d’expiration qui renseigne le navigateur sur la date de suppression du cookie. Si un cookie ne contient pas de valeur d’expiration, le navigateur le supprimera lorsque l’utilisateur/trice fermera la fenêtre de celui-ci. Vous pouvez controler le comportement du framework de session concernant ceci grâce au paramètre SESSION_EXPIRE_AT_BROWSER_CLOSE.

Par défaut, SESSION_EXPIRE_AT_BROWSER_CLOSE est placé à False, ce qui signifie que les cookies de sessions seront stockés dans les navigateurs des utilisateurs durant SESSION_COOKIE_AGE seconde(s) (qui est de deux semaines par défaut ou 1,209,600 secondes). Utilisez ceci si vous ne voulez pas que les personnes aient à se connecter à chaque fois qu’elles ouvrent un navigateur.

Si SESSION_EXPIRE_AT_BROWSER_CLOSE est placée à True, Django utilisera un cookie temporaire.

Autres paramètres de session

En dehors des paramètres déjà mentionnés, d’autres paramètres influencent la manière dont le framework de sessions Django utilise les cookies, comme le montre le tableau 12-2.

Tableau 12-2. Paramètres influant sur le comportement d’un cookie

Activer le support d’autentification

Tout comme les outils de session, le support d’identification est livré sous forme d’application Django dans django.contrib, qui doit être installé. Comme le système de session, il est installé par défaut, mais si vous l’avez supprimé, vous devrez suivre ces étapes pour lm’installer:

1. Assurez-vous que le framework de session soit installé tel que décrit plus tôt dans ce chapitre. Conserver les traces des utilisateurs requiert évidemment des cookies, et ceux-ci sont construits par le framework de session.
2. Placez 'django.contrib.auth' dans votre paramètre INSTALLED_APPS puis lancez manage.py syncdb.
3. Assurez-vous que 'django.contrib.auth.middleware.AuthenticationMiddleware' soit dans votre paramètre MIDDLEWARE_CLASSES après SessionMiddleware.

Avec cette installation, nous sommes prêts à manipuler des utilisateurs dans les fonctions vues. L’interface principale que vous utiliserez pour accéder aux utilisateurs au sein d’une vue est request.user; c’est un objet qui représente l’utilisateur actuellement connecté. Si l’utilisateur n’est pas connecté, il sera considéré comme un objet ANonymousUser (voir plus loin pour les détails).

Vous pouvez facilement dire si un utilisateur est connecté avec la méthode is_authenticated():

if request.user.is_authenticated():
    # Do something for authenticated users.
else:
    # Do something for anonymous users.

Utiliser les utilisateurs

Une fois que vous avez un User - souvent depuis request.user, mais aussi potentiellement grâce à l’une des autres méthodes rapidement abordées - vous avez des nombreux champs et méthodes disponiblent sur cet objet. Les objets AnonymousUser émulent une partie de cette interface, mais pas complétement, vous devez donc contrôler user.is_authenticated() avant de considérer que vous avez affaire à un objet utilisateur de bonne foi. Les tableaux 12-3 et 12-4 listent les champs et les méthodes sur les objets User, respectivement.

Tableau 12-3. Champs des objets User

Tableau 12-4. Méthodes des objets User

Finalement, les objets User ont deux champs plusieur-à-plusieur: groups et permissions. Les objets User peuvent accéder à leurs objets liés de la même façon que tout autre champ plusieur-à-plusieur:

# Set a user's groups:
myuser.groups = group_list

# Add a user to some groups:
myuser.groups.add(group1, group2,...)

# Remove a user from some groups:
myuser.groups.remove(group1, group2,...)

# Remove a user from all groups:
myuser.groups.clear()

# Permissions work the same way
myuser.permissions = permission_list
myuser.permissions.add(permission1, permission2, ...)
myuser.permissions.remove(permission1, permission2, ...)
myuser.permissions.clear()

Connexion et déconnexion

Django fourni des vues pour gérer la connexion et la déconnexion (et autres astuces géniales), mais avant d’en arriver là, étudions la manière de connecter et déconnecter des utilisateurs «à la main». Django fournit deux fonctions dans django.contrib.auth pour faire ces actions: authenticate() et login().

Pour identifier les noms et mot de passe d’un utilisateur donné, utilisez authenticate(). Elle accepte deux arguments mot-clef, username et password, et retourne un objet User si le mot de passe est valide pour le nom d’utilisateur donné. Si le mot de passe est invalide, authenticate() renvoie None:

>>> from django.contrib import auth
>>> user = auth.authenticate(username='john', password='secret')
>>> if user is not None:
...     print "Correct!"
... else:
...     print "Oops, that's wrong!"

authenticate() vérifie uniquement les références de l’utilisateur. Pour connecter un utilisateur, utilisez login(). Elle prends un objet HttpRequest et un objet User puis enregistre l’ID de l’utilisateur dans la session, en utilisant le framework de session Django.

Cet exemple vous montre comment vous pouvez urtiliser à la fois authenticate() et login() à l’intérieur d’une vue:

from django.contrib import auth

def login(request):
    username = request.POST['username']
    password = request.POST['password']
    user = auth.authenticate(username=username,
    password=password)
    if user is not None and user.is_active:
        # Correct password, and the user is marked "active"
        auth.login(request, user)
        # Redirect to a success page.
        return HttpResponseRedirect("/account/loggedin/")
    else:
        # Show an error page
        return HttpResponseRedirect("/account/invalid/")

Pour déconnecter un utilisateur, utilisez django.contrib.auth.logout() dans votre vue. Elle prends un objet HttpRequest et n’a pas de valuer de retour:

from django.contrib import auth

def logout(request):
    auth.logout(request)
    # Redirect to a success page.
    return HttpResponseRedirect("/account/loggedout/")

Notez que logout() ne lève aucune erreurs si l’utilisateur n’est pas connecté.

En pratique, vous n’aurez habituellement pas besoin d’écrire vos propres fonctions de «login/logout»; le système d’identification est livré avec un jeu de vues génériques pour prendre en charge la connexion et la déconnexion.

La première étape dans l’utilisation des vues d’identification est de les ajouter à votre URLconf. Vous devrez ajouter cet extrait :

from django.contrib.auth.views import login, logout

urlpatterns = patterns('',
    # existing patterns here...
    (r'^accounts/login/$',  login),
    (r'^accounts/logout/$', logout),
)

/accounts/login/ et /accounts/logout/ sont les URLs par défaut que Django utilise pour ces vues.

Par défaut, la vue login renvoie génère un gabarit à l’adresse registration/login.html (vous pouvez changer le nom de ce gabarit en passant un argument à la vue, template_name). Ce formulaire doit contenir un champ username et un champ password. Un simple gabarit doit resssembler à ceci:

{% extends "base.html" %}

{% block content %}

  {% if form.errors %}
    <p class="error">Sorry, that's not a valid username or
    password</p>
  {% endif %}

  <form action='.' method='post'>
    <label for="username">User name:</label>
    <input type="text" name="username" value="" id="username">
    <label for="password">Password:</label>
    <input type="password" name="password" value=""
    id="password">

    <input type="submit" value="login" />
    <input type="hidden" name="next" value="{{ next|escape }}" />
  </form>

{% endblock %}

Si l’utilisateur/trice se connecte avec succès, il ou elle sera redirigée vers /accounts/profile/ par défaut. Vous pouvez outrepasser cela en ajoutant un champ caché appelé next avec l’URL de redirection une fois la connection établie. Vous pouvez aussi transmettre cette valeur sous forme de paramètre GET à la vue de connexion et elle sera automatiquement ajoutée au contexte en tant que varaible nommée next que vous pouvez insérer dans ce champ caché.

La vue de déconnexion fonctionne un peu différement. Par défaut elle génère un gabarit à l’adresse registration/logged_out.html (qui contient habituellement un message «Vous êtes bien déconnecté»). Cependant, vuos pouvez appeler la vue avec un argument supplémentaire, next_page, qui informera la vue de faire une redirection après une déconnexion.

Limiter l’accès des utilisateurs connectés

Bien sûr, la raison pour laquelle nous sommes tous passez par ces ennuis est que nous voulons limiter l’accès à certaines parties du site.

La façon simple, brute, de limiter l’acces à certaines pages est de controler request.user.is_authenticated() puis de rediriger vers une page de login:

from django.http import HttpResponseRedirect

def my_view(request):
    if not request.user.is_authenticated():
        return HttpResponseRedirect('/login/?next=%s' %
        request.path)
    # ...

ou bien afficher un message d’erreur:

def my_view(request):
    if not request.user.is_authenticated():
        return render_to_response('myapp/login_error.html')
    # ...

Pour allez plus vite, vous pouvez utiliser le bien pratique décorateur, login_required:

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    # ...

login_required procède de la sorte:

• si l’utilisateur n’est pas connecté, elle redirige vers /accounts/login/, passant l’URL absolut courant dans la chaîne de requête sous forme de next, par exemple: /accounts/login/?next=/polls/3/.
• si l’utilisateur est connecté, exécute la vue normalement. Le code de la vue peut ensuite considérer que l’utilisateur est connecté.

Limiter l’acces aux utilisateurs passant un test

Limiter l’accès basé sur selon certaines permissions ou sur un autre test, et fournir un emplacement différent pour la vue de connexion, tout ceci fonctionne essentiellement de la même manière.

La méthode brute consiste à lancer votre test sur le request.user directement dans la vue. Par exemple, cette vue s’assure que l’utilisateur est connecté et qu’il possède l’autorisation polls.can_vote (des détails sur le fonctionnement des autorisations suivent):

def vote(request):
    if request.user.is_authenticated() and
    request.user.has_perm('polls.can_vote')):
        # vote here
    else:
        return HttpResponse("You can't vote in this poll.")

Encore une fois, Django fourni un raccourcis appelé user_passes_test. Il accepte des arguments et génère un décorateur spécialisé selon votre situation particulière:

def user_can_vote(user):
    return user.is_authenticated() and
    user.has_perm("polls.can_vote")

@user_passes_text(user_can_vote, login_url="/login/")
def vote(request):
    # Code here can assume a logged-in user with the correct
    permission.
    ...

user_passes_test impose un argument: un «callable» qui prends un objet User et renvoie True si l’utilisateur est autorisé à voir la page. Notez que user_passes_test ne vérifie pas automatiquement que le User est identifé; vous devez faire cela par vous même.

Dans cet exemple nous montrons aussi le deuxième argument optionnel, login_url, qui vous permet de préciser l’URL de votre page de connection (/accounts/login/ par défaut).

Puisque vérifier si un utilisateur possède une autorisation particulière est une tâche relativement courant, Django fourni un raccourcis pour ce cas précis: le décorateur permission_required(). En utilisant ce décorateur, l’exemple précédent peut-être écrit comme suit:

from django.contrib.auth.decorators import permission_required

@permission_required('polls.can_vote', login_url="/login/")
def vote(request):
    # ...

Notez que permission_required() accepte aussi un paramètre optionnel login_url, qui est aussi '/accounts/login/' par défaut.

from dango.contrib.auth.decorators import login_required
from django.views.generic.date_based import object_detail

@login_required
def limited_object_detail(*args, **kwargs):
    return object_detail(*args, **kwargs)

Gérer les utilisateurs, les autorisations, et les groupes

La façon de loin la plus simple pour gérer le système d’autentification est d’utiliser l’interface d’administration. Le chapitre 6 aborde la façon d’utiliser l’interface d’administration de Django pour éditer les utilisateurs et contrôler leurs permissions et leurs accès. La plupart du temps vous utiliserez uniquement cette interface.

Cependant, il existe un API de bas niveau que vous pouvez explorer lorsque vous avez besoin d’un contrôle absolu, et nous discuterons de cela dans les sections qui suivent.

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user(username='john',
...                                 email='jlennon@beatles.com',
...                                 password='glass onion')

>>> user.is_staff = True
>>> user.save()

>>> user = User.objects.get(username='john')
>>> user.set_password('goo goo goo joob')
>>> user.save()

hashtype$salt$hash

sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4

from django import oldforms as forms
from django.http import HttpResponseRedirect
from django.shortcuts import render_to_response
from django.contrib.auth.forms import UserCreationForm

def register(request):
    form = UserCreationForm()

    if request.method == 'POST':
        data = request.POST.copy()
        errors = form.get_validation_errors(data)
        if not errors:
            new_user = form.save(data)
            return HttpResponseRedirect("/books/")
    else:
        data, errors = {}, {}

    return render_to_response("registration/register.html", {
        'form' : forms.FormWrapper(form, data, errors)
    })

{% extends "base.html" %}

{% block title %}Create an account{% endblock %}

{% block content %}
  <h1>Create an account</h1>
  <form action="." method="post">
    {% if form.error_dict %}
      <p class="error">Please correct the errors below.</p>
    {% endif %}

    {% if form.username.errors %}
      {{ form.username.html_error_list }}
    {% endif %}
    <label for="id_username">Username:</label> {{ form.username
    }}

    {% if form.password1.errors %}
      {{ form.password1.html_error_list }}
    {% endif %}
    <label for="id_password1">Password: {{ form.password1 }}

    {% if form.password2.errors %}
      {{ form.password2.html_error_list }}
    {% endif %}
    <label for="id_password2">Password (again): {{ form.password2
    }}

    <input type="submit" value="Create the account" />
  </label>
{% endblock %}

Utiliser les données d’identification dans les gabarits

L’utilisateur actuellement connecté ainsi que ses permissions sont rendus disponibles dans le gabarit contextuel lorsque vous utilisez RequestContext (voir le chapitre 10).

En utilisant RequestContext, l’utilisateur courant (soit une instance de User, soit une instance de AnonymousUser) est stocké dans la variable de gabarit {{ user }}:

{% if user.is_authenticated %}
  <p>Welcome, {{ user.username }}. Thanks for logging in.</p>
{% else %}
  <p>Welcome, new user. Please log in.</p>
{% endif %}

Les permissions de l’utilisateur sont stocké dans la variable de gabarit {{ perms }}. C’est un proxy, ouvert aux gabarits, vers un jeu de méthodes d’autorisations décrites d’ici peu.

Il existe deux façons d’utiliser cet objet perms. Vous pouvez utiliser quelque chose comme {{ perms.polls }} pour vérifier si l’utilisateur possède certaines permissions pour une application données, ou vous pouvez utiliser quelque chose comme {{ perms.polls.can_vote }} pour vérifier si l’utilisateur à des permissions spécifiques.

Ainsi, vous pouvez vérifier les permissions dans les instructions {% if %} de gabarit:

{% if perms.polls %}
  <p>You have permission to do something in the polls app.</p>
  {% if perms.polls.can_vote %}
    <p>You can vote!</p>
  {% endif %}
{% else %}
  <p>You don't have permission to do anything in the polls app.</p>
{% endif %}

Permissions

Les permissions sont une manière simple de «marquer» les utilisateurs et les groupes comme étant capable de faire certaines actions. Elles sont généralement utilisées par le site d’administration de Django, mais vous pouvez aisément les utiliser dans votre propre code.

Le site d’administration de Django utilise les permissions suivantes:

• l’accès à la vue du formulaire d’ajout, ainsi qu’à l’ajout d’objet se limite aux utilisateur sayant la permission add pour ce type d’objet.
• l’accès à la vue de la liste des modifications, à la vue du formulaire de modification, ainsi qu’à la modification d’un objet est limitée aux utilisateurs ayant la permission change pour ce type d’objet.
• l’accès à la suppression d’objet est limité aux utilisateurs ayant la permission delete pour ce type d’objet.

Les permissions sont fixé globalement par type d’objet, et non pas par instance spécifique d’objet. Par exemple, il est possible de dire «Mary peut modifier les actualités», mais il n’est pas actuellement possible de dire «Mary peut changer les actualités, mais uniquement celles qu’elle a crée elle-même» ou «Mary peut changer uniquement les actualités qui ont un certains status, une certaine date de publication, ou un certain ID».

Ces trois permissions de base - ajout, modification, suppression - sont automatiquement crées pour chaque modèle Django possédant une class Admin. En coulisses, ces permissions sont ajouté à la base de données auth_permission lorsque vous lancez la commande manage.py syncdb.

Ces permissions seront de la forme "<app>.<action>_<object_name>". Ceci dit, si vous avez une application polls avec un modèle Choice, vous obtiendrez des permissions nommées "polls.add_choice", "polls.change_choice", et "polls.delete_choice".

Notez que si votre modèle n’a pas de class Admin lorsque vous lancez syncdb, les permissions ne seront pas crées. Si vous initialisez votre base de données et ajoutez class Admin aux modèles après cela, vous devrez à nouveau lancer syncdb pour créer toutes lespermissions manquantes pour vos applicationsinstallées.

Vous pouvez aussi créer des permissions personnalisées pour un objet donné, en utilisant l’attribut permissions sur Meta. Cet exemple de modèle crée trois permissions personnalisées:

class USCitizen(models.Model):
   # ...
   class Meta:
       permissions = (
           # Permission identifier     human-readable
           permission name
           ("can_drive",               "Can drive"),
           ("can_vote",                "Can vote in
           elections"),
           ("can_drink",               "Can drink
           alcohol"),
       )

Ce code créer ces permissions supplémentaires uniquement lorsque vous lancez syncdb; il vous revient de vérifier ces permissions dans vos vues.

Tout comme les utilisateurs, les permissions sont implémentées dans un modèle Django se trouvant dans django.contrib.auth.models. Cela signifie que vous pouvez utiliser l’API de base de données de Django pour agir directement sur les permissions si vous le désirez.

Groupes

Les groupes sont une façon générique de catégoriser les utilisateurs de façon à pouvoir appliquer des permissions, ou d’autres étiquettes, à ces utilisateurs. Un utilisateur peut appartenir à plusieurs groupes.

Un utilisateur dans un groupe obtient automatiquement les autorisations accordées à ce groupe. Par exemple, si le groupe Site editors possède l’autorisation can_edit_home_page, tous les utilisateurs de ce groupe auront cette autorisation.

Les groupes sontaussi une façon commode de catégoriser les utilisateurs de façon à leur donner certinaes étiquettes, ou des fonctionnalités étendues. Par exemple, vouspouvez créer un groupe 'Special users', et vous pouvez écrire du code qui, admettons, donne à ces utilisateurs un accès à une partie du site réservée uniquement aux membres, ou envoie des courrièls uniquement aux membres.

Comme pour les utilisateurs, la manière la plus simple de gérer des groupes est d’utiliser l’interface d’administration. Cependant, les groupes sont aussi de simples modèles Django qui résident dans django.contrib.auth.models, ainsi là encore vous pouvez toujours utiliser l’API de base de données de Django pour gérer les groupes au plus bas niveau.

Messages

Le système de message est une façon légère de faire une file d’attente des messages pour des utilisateurs donnés. Un message est associé à un User. Il n’y a pas de concept d’expiration ou d’horodatage.

Les messages sont utilisés par l’interface d’administratino de Django après une série d’actions réussies. Par exemple, lorsque vous créez un objet, vous remarquerez un message «L’objet à été crée avec succès» en haut de la page d’administration.

Vous pouvez utiliser la même API pour faire une file et afficher les messages dans votre propre application. L’API est simple:

• pour créer un nouveau message, utilisez user.message_set.create(message='message_text').
• pour récupérer/supprimer des messages, utilisez user.get_and_delete_messages(), qui retourne une liste des objets Message dans la file de l’utilisateur (s’il existe) et supprime les messages de la file.

Dans cet exemple de vue, le système enregistre un message pour l’utilisateur après avoir créé une liste de lecture:

def create_playlist(request, songs):
    # Create the playlist with the given songs.
    # ...
    request.user.message_set.create(
        message="Your playlist was added successfully."
    )
    return render_to_response("playlists/create.html",
        context_instance=RequestContext(request))

Lorsque vous utilisez RequestContext, l’utilisateur actuellement connecté ainsi que son message sont rendu disponibles dans le contexte de gabarit sous la forme de la variable {{ messages }}. Voici un exemple de code d’un gabarit qui affiche les messages:

{% if messages %}
<ul>
    {% for message in messages %}
    <li>{{ message }}</li>
    {% endfor %}
</ul>
{% endif %}

Notez que les appels à RequestContext get_and_delete_messages (récupèrent_et_suppriment_les_messages) en coulisses, ainsi tout message sera effacé même si vous ne les affichez pas.

Finallement, notez que ce framework de message fonctionne uniquement avec les utilisateurs existant dans la base de données des utilisateurs. Pour envoyer un message à un utilisateru anonyme, utilisez directement le framework de session.

Profiles

La pièce finale du puzzle est le système de profile. Pour comprendre ce que sont les profiles , jetons un oeil au problème.

En résumé, beaucoup de site ont besoin de stocker plus d’information sur l’utilisateur que celle disponible dans l’objet User standard. Pour limiter le problème, la plupart des sites auront des champs «supplémentaires». Ainsi, Django fourni une manière légère de définir un objet «profile» qui est lié à un utilisateur donné. Cet objet profile peut différer de projet en projet, et peut même gérer différents profiles pour différents sites servis depuis la même base de données.

la première étape dans la création d’un profile est de définir un modèle qui porte les informations de profil. Le seul pré requis qu’impose Django est de définir un modèle qui possède une unique ForeignKey vers le modèle User; ce champ doit s’appeler user. Mis à part cela, vous pouvez utiliser autant de champs que vous le désirez. Voici un modèle de profile totalement arbitraire:

from django.db import models
from django.contrib.auth.models import User

class MySiteProfile(models.Model):
    # This is the only required field
    user = models.ForeignKey(User, unique=True)

    # The rest is completely up to you...
    favorite_band = models.CharField(maxlength=100, blank=True)
    favorite_cheese = models.CharField(maxlength=100, blank=True)
    lucky_number = models.IntegerField()

Ensuite, vous devrez indiquer à Django où il doit chercher cet objet profil. Vous faites cela en paramètrant AUTH_PROFILE_MODULE selon l’identifiant de votre modèle. Donc, si votre modèle réside dans une application appelée myapp, vous placerez ceci dans votre fichier de paramètres:

AUTH_PROFILE_MODULE = "myapp.mysiteprofile"

Une fois ceci fait, vous pouvez accéder à un profil utilisateur en appelant user.get_profile(). Cette fonction peut lever une exception SiteProfileNotAvailable si AUTH_PROFILE_MODULE n’est pas défini, ou elle peut lever une exception DoesNotExist si l’utilisateur ne possède pas de profil (généralement, vous récupérerez cette exception pour créer un nouveau profile à ce moment là).