Le livre de

Scénario 1: Réutiliser les données sur des multiples sites

Comme expliqué au chapitre 1, les sites sous Django que sont LJWorld.com et Lawrence.com sont gérer par le même groupe de presse: le journal Lawrence Journal-World à Lawrence, Kansas. LJWorld.com se concentre sur les informations, alors que Lawrence.com traite surtout les divertissements locaux. Mais parfois, les éditeurs veulent publier un article sur les deux sites.

La manière casse-tête de résoudre le problème serait d’utiliser des bases de données séparées pour chaque site et d’imposer aux rédacteurs de publier la même histoire deux fois: pour le LJWorld.com et à nouveau pour Lawrence.com. Mais ceci est inefficace pour les rédacteurs, et il est redondant de stocker de multiples copies de la même histoire dans la base de données.

La meilleure solution est que les deux sites utilisent la même base de données des articles, et qu’un article soit associé à un ou plusieurs sites via une relation plusieurs-à-plusieurs. Le framework de site sous Django fournit la talbe en base de données dans laquelle les articles peuvent êtres liés. C’est un moyen d’associer les données avec un ou plusieurs «sites».

Scenario 2: Stocker le nom/domaine de votre site en un seul endroit

LJWorld.com et Lawrence.com ont touts deux des fonctionnalités d’alerte mail, qui permettent aux lecteurs inscrit d’être averti dès qu’une nouvelle actualité arrive. C’est assez simple: un lecteur s’inscrit sur un formulaire web, et reçoit immédiatement une courrier lui disant, «Merci pour votre inscription».

Il serait inefficace et redondant d’implémenter le code de ce processus d’inscription deux fois, les sites utilisent donc le même code en coulisses. Mais le message «Merci pour votre inscription» peut être différent pour chaque site. En utilisant les objets Site, nous pouvons faire en sorte que le message de remerciement utilise les valeurs name (par exemple, 'LJWorld.com') et domain (par exemple, 'www.ljworld.com') du site courant.

Le framework de sites sous Django fournit un espace pour vous permettre de stocker le name et le domain pour chaque site dans votre projet Django, ce qui signifie que vous pouvez réutiliser ces valeurs de manière générique.

Comment utiliser le Framework de sites

Le framework de sites est plus une série de conventions qu’un framework. Tout est basé sur deux concepts simples:

• Le modèle Site, qui se trouve dans django.contrib.sites, possède des champs domain et name.
• Le paramètre SITE_ID spécifie l’ID de la base de données de l’objet Site associé à ce fichier de paramètres particulier.

La façon dont vous utilisez ces deux concepts est laissé à votre discrétion, mais Django les utilise automatiquement dans certaines occasions via des conventions simples.

Pour installer l’application sites, suivez ces étapes:

1. Ajoutez 'django.contrib.sites' à votre INSTALLED_APPS.
2. Lancez la commande manage.py syncdb pour installer la table django_site dans votre base de données.
3. Ajoutez un ou plusieurs objets Site, soit au travers de l’interface d’administration de Django soit via l’API Python. Créez un objet Site pour chaque site/domaine que ce projet Django motorise.
4. Definissez le paramètre SITE_ID dans chacun de vos fichiers de paramètres. Cette valeur doit correspondre à l’ID de base de données de l’objet Site pour le site correspondant à ce fichier de paramètres.

Les possibilités du framework Sites

Les sections qui suivent décrivent les diverses choses que vouspouvez faire avec le framework de sites.

from django.db import models
from django.contrib.sites.models import Site

class Article(models.Model):
    headline = models.CharField(maxlength=200)
    # ...
    sites = models.ManyToManyField(Site)

from django.conf import settings

def article_detail(request, article_id):
    try:
        a = Article.objects.get(id=article_id,
        sites__id=settings.SITE_ID)
    except Article.DoesNotExist:
        raise Http404
    # ...

from django.db import models
from django.contrib.sites.models import Site

class Article(models.Model):
    headline = models.CharField(maxlength=200)
    # ...
    site = models.ForeignKey(Site)

from django.conf import settings

def my_view(request):
    if settings.SITE_ID == 3:
        # Do something.
    else:
        # Do something else.

from django.conf import settings
from django.contrib.sites.models import Site

def my_view(request):
    current_site = Site.objects.get(id=settings.SITE_ID)
    if current_site.domain == 'foo.com':
        # Do something
    else:
        # Do something else.

from django.contrib.sites.models import Site

def my_view(request):
    current_site = Site.objects.get_current()
    if current_site.domain == 'foo.com':
        # Do something
    else:
        # Do something else.

from django.contrib.sites.models import Site
from django.core.mail import send_mail

def register_for_newsletter(request):
    # Check form values, etc., and subscribe the user.
    # ...
    current_site = Site.objects.get_current()
    send_mail('Thanks for subscribing to %s alerts' %
    current_site.name,
        'Thanks for your subscription. We appreciate
        it.\n\n-The %s team.' % current_site.name,
        'editor@%s' % current_site.domain,
        [user_email])
    # ...

from django.core.mail import send_mail
from django.template import loader, Context

def register_for_newsletter(request):
    # Check form values, etc., and subscribe the user.
    # ...
    subject =
    loader.get_template('alerts/subject.txt').render(Context({}))
    message =
    loader.get_template('alerts/message.txt').render(Context({}))
    send_mail(subject, message, 'do-not-reply@example.com',
    [user_email])
    # ...

>>> from django.contrib.sites.models import Site
>>> obj = MyModel.objects.get(id=3)
>>> obj.get_absolute_url()
'/mymodel/objects/3/'
>>> Site.objects.get_current().domain
'example.com'
>>> 'http://%s%s' % (Site.objects.get_current().domain,
obj.get_absolute_url())
'http://example.com/mymodel/objects/3/'

CurrentSiteManager

Si Site``s jou un rôle clef dans votre application, considérez l'utilisation du bien pratique ``CurrentSiteManager dans vos modèles. C’est un gestionnaire de modèle (voir l’annexe B) qui filtre automatiquement ses requêtes afin d’y inclure uniquement les objets associés au Site courant.

Utilisez CurrentSiteManager en l’ajoutant à votre modèle explicitement. Par exemple:

from django.db import models
from django.contrib.sites.models import Site
from django.contrib.sites.managers import CurrentSiteManager

class Photo(models.Model):
    photo = models.FileField(upload_to='/home/photos')
    photographer_name = models.CharField(maxlength=100)
    pub_date = models.DateField()
    site = models.ForeignKey(Site)
    objects = models.Manager()
    on_site = CurrentSiteManager()

Avec ce modèle, Photo.objects.all() retournera tous les objets Photo de la base de données, alors que Photo.on_site.all() retournera uniquement les objets Photo associés au site courant, conformément au paramètre SITE_ID.

En d’autre termes, ces deux instructions sont équivalentes:

Photo.objects.filter(site=settings.SITE_ID)
Photo.on_site.all()

Comment CurrentSiteManager à su que le champ Photo était celui de Site? Il recherche par défaut un champ appelé site. Si votre modèle possède une ForeignKey ou un ManyToManyField appelé autrement que site, vous devrez explicitement préciser cela sous forme de paramètre de CurrentSiteManager. Le modèle suivant, qui propose un champ appelé publish_on, démontre ceci:

from django.db import models
from django.contrib.sites.models import Site
from django.contrib.sites.managers import CurrentSiteManager

class Photo(models.Model):
    photo = models.FileField(upload_to='/home/photos')
    photographer_name = models.CharField(maxlength=100)
    pub_date = models.DateField()
    publish_on = models.ForeignKey(Site)
    objects = models.Manager()
    on_site = CurrentSiteManager('publish_on')

Si vous essayez d’utiliser CurrentSiteManager en lui passant le nom d’un champ qui n’existe pas, Django lévera une ValueError.

Comment Django utilise le framework Sites

Bien que l’utilisation du framework de sites ne soit pas requise, elle est fortement encouragée, car ainsi Django en bénéficie en divers endroits. Même si votre installation Django motorise un seul site, vous devriez prendre quelques secondes pour créer l’objet site avec votre domain et votre name, et pointer sur son ID dans votre paramètre SITE_ID.

Voici comment Django utilise le framework de sites:

• Dans le framework de redirection (consulter la section «Redirtections» plus après), chaque objet redirection est associé à un site particulier. Lorsque Django recherche une redirection, il prend en compte le SITE_ID courant.
• Dans le framework de commentaires, chaque commentaire est associé à un site particulier. Lorsqu’un commentaire est posté, son site prends la valeur du SITE_ID courant, et lorsque les commentaires sont listés via la balise de gabarit appropriée, seuls les commentaires pour le site courant sont affichés.
• Dans le framework de pages statiques (voir la section «Pages statique» à suivre), chaque page statique est associée à un site particulier. Lorsqu’une page statique est créée, vous spécifiez son site, et le middleware de page statique vérifie le SITE_ID courant en récupérant les pages statiques à afficher.
• Dans le framework de syndication (voir les chapitre 11), les gabarits pour title et description ont automatiquement accès à une variable {{ site }}, qui est l’objet Site représentant le site courant. De même, l’accroche pour fournir les éléments d’URLs utilisera le domain de l’objet Site courant si vous ne spécifiez pas un nom de domaine pleinement qualifié.
• Dans le framwork d’identification (voir le chapitre 12), la vue django.contrib.auth.views.login transmet le nom du Site courant au gabarit {{ site_name }}.

Using Flatpages

Pour installer l’application «flatpages», suivez ces étapes:

1. Ajoutez 'django.contrib.flatpages' à votre INSTALLED_APPS. django.contrib.flatpages dépend de django.contrib.sites, assurez vous donc que les deux paquets soient bien parmis les INSTALLED_APPS.
2. Ajoutez 'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware' à votre paramètre MIDDLEWARE_CLASSES.
3. Lancez la commande manage.py syncdb pour installer les deux tables requises dans votre base de données.

L’application pages statiques crée deux tables dans votre base de données: django_flatpage et django_flatpage_sites. django_flatpage met simplement en correspondance un URL avec un titre maps a URL to a title and bunch of text content. django_flatpage_sites is a many-to-many table that associates a flatpage with one or more sites.

L’application est livrée avec un seul modèle FlatPage, défini dans django/contrib/flatpages/models.py. Il ressemble à ceci:

from django.db import models
from django.contrib.sites.models import Site

class FlatPage(models.Model):
    url = models.CharField(maxlength=100)
    title = models.CharField(maxlength=200)
    content = models.TextField()
    enable_comments = models.BooleanField()
    template_name = models.CharField(maxlength=70, blank=True)
    registration_required = models.BooleanField()
    sites = models.ManyToManyField(Site)

Examinons ces champs un par un:

• url: l’URL où réside la page statique, purgée du nom de domaine mais incluant la barre oblique initiale (par exemple, /about/contact/).
• title: le titre de la page statique. Le framework n’en fait rien de spécial. C’est à vous de l’afficher dans votre gabarit.
• content: le contenu de la page statique (c’est à dire, le HTML de la page). Le framework n’en fait rien de spécial. C’est à vous de l’afficher dans votre gabarit.
• enable_comments: permet d’activer ou non les commentaires sur cette page statiques. Le framework n’en fait rien de spécial. Vous pouvez utliser cette valeur dans votre gabarit et afficher un formulaire de commentaires si besoin.
• template_name: le nom du gabarit à utiliser pour le rendu de cette page statique; Ceci est optionel; Si rien n’est précisé ou si ce gabarit n’existe pas, le framework se retournera vers le template flatpages/default.html.
• registration_required: indique si l’identification est requise pour voir cette page statique. Ceci s’interface avec le framework identification/utilisateur de Django, qui est détaillé plus au chapitre 12.
• sites: les sites pour lesquels cette page statique est disponible. Ceci s’interface avec le framework de sites Django, qui est détaillé dans la section «Sites» de ce chapitre.

Vous pouvez créer des pages statiques soit au travers de l’interface d’administration de Django soit l’API de base de données de Django. Pour plus d’information sur ce sujet, consultez la section «Ajouter, modifier et supprimer des pages statiques».

Une fois que vous avez créé des pages statiques, FlatpageFallbackMiddleware fait tout le travail. Chaque fois qu’une application Django lève une erreur 404, ce middleware cherche l’URL requis en dernier recours dans la base de données des pages statiques. Plus précisément, il cherche une page statique ayant l’URL données et un ID de site qui correspond au paramètre SITE_ID.

S’il trouve une correspondance, il charge le gabarit de page statique ou le flatpages/default.html si la apge statique ne spécifie pas de gabarit personnalisé. Il passe à ce gabarit une unique variable de contexte, flatpage, qui est l’objet flatpage. Il utilise RequestContext lors du rendu de gabarit.

Si FlatpageFallbackMiddleware ne trouve pas de correspondance, la requête continue d’être traitée, comme d’habitude.

Ajouter, modifier et supprimer des pages statiques

Vouspouvez ajouter, modifier et supprimer des pages statiques de deux façons:

>>> from django.contrib.flatpages.models import FlatPage
>>> from django.contrib.sites.models import Site
>>> fp = FlatPage(
...     url='/about/',
...     title='About',
...     content='<p>About this site...</p>',
...     enable_comments=False,
...     template_name='',
...     registration_required=False,
... )
>>> fp.save()
>>> fp.sites.add(Site.objects.get(id=1))
>>> FlatPage.objects.get(url='/about/')
<FlatPage: /about/ -- About>

Utiliser les gabarits de pages statiques

Par défaut, les pages statiques sont rendues via le gabarit flatpages/default.html, mais vous pouvez outre-passer cela pour une page statique précise avec le champ template_name de l’objet FlatPage.

Créer le gabarit flatpages/default.html reste de votre ressort. Dans votre répertoire de gabarit, créez simplement un répertoire flatpages contenant un fichier default.html.

Les gabarits de pages statiques récupère une variable de contexte unique, flatpage, qui est l’objet flatpage.

Voici un échantillon de gabarit flatpages/default.html:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
    "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<title>{{ flatpage.title }}</title>
</head>
<body>
{{ flatpage.content }}
</body>
</html>

Utiliser le framework de redirection

Pour installer l’application «redirects», suivez ces étapes:

1. Ajouter 'django.contrib.redirects' à votre INSTALLED_APPS.
2. Ajouter 'django.contrib.redirects.middleware.RedirectFallbackMiddleware' à votre paramètre MIDDLEWARE_CLASSES.
3. Lancez la commande manage.py syncdb pour installer l’unique table requise dans votre base de données.

manage.py syncdb crée une table django_redirect dans votre bases de données. C’est une simple table de recherche sur les champs site_id, old_path, et new_path.

Vous pouvez créer des redirections soit au travers de l’interface d’administration soit grâce à l’API de base de données de Django. Pour en savoir plus, lisez la section «Ajouter, modifier et supprimer des redirections».

Lorsque vous avez crée des redirections, la classe RedirectFallbackMiddleware fait tout le travail. Chaque fois qu’une application Django lève une erreur 404, ce middleware cherche l’URL requis en dernier recours dans la base de données des redirections.

Plus précisément, il cherche une redirection ayant le old_path donné et ayant un ID de site qui corresponde au paramètre SITE_ID. (Lisez la section précédente «Sites» pour en savoir plus au sujet de SITE_ID et du framework de sites). Il suit ensuite ces étapes:

• S’il trouve une correspondance, et que new_path nest pas vide, il redirige vers new_path.
• S’il trouve une correspondance, et que new_path est vide, il envoi une en-tête 410 («Page déplacée») et une réponse vide (sans contenu).
• S’il ne trouve pas de correspondance, la requête continue d’être traitée comme d’habitude.

Le middleware ne s’active que pour les erreurs 404 - pas pour les erreurs 500 ou tout autre code de status.

Notez quell’ordre des MIDDLEWARE_CLASSES importe. Usuellement, vous placerez RedirectFallbackMiddleware tout au bout de la liste, puisque c’est une dernier recours.

Ajouter, modifier et supprimer des redirections

Vous pouvez ajouter, modifier et supprimer les redirections de deux façons:

>>> from django.contrib.redirects.models import Redirect
>>> from django.contrib.sites.models import Site
>>> red = Redirect(
...     site=Site.objects.get(id=1),
...     old_path='/music/',
...     new_path='/sections/arts/music/',
... )
>>> red.save()
>>> Redirect.objects.get(old_path='/music/')
<Redirect: /music/ ---> /sections/arts/music/>

Un exemple simple de CSRF

Supposons que vous soyez identifié sur un compte de la messagerie web example.com. Ce site de messagerie propose un bouton de déconnexion qui pointe vers l’URL example.com/logout - autrement dit, l’unique action que vous avez besoin de faire pour vous déconnecter est de visiter la page example.com/logout.

Un site malicieu peut vous contraindre à visiter l’URL example.com/logout en incluant cette URL dissimulée dans un <iframe> sur sa propre page (malicieuse). Ainsi, si vous êtes connecté sur le compte de messagerie example.com et que vous visitiez la page malicieuse qui possède un <iframe> vers example.com/logout, le fait de visiter la page malicieuse vous déconnectera d’example.com. Clairement, être déconnecté d’un site de messagerie contre votre volonté n’est pas une terrible faille de sécurité, mais ce même type d’exploit peut arriver à n’importe quel site qui «identifie» les utilisateurs, tel qu’un site de compte bacaire en ligne ou un site de e-commerce.

Un example plus complexe de CSRF

Dans l’exemple précédent, example.com était partiellement en faute parce qu’il autorisait un changement d’état (c’est à dire, déconnecter l’utilisateur) à être appelé depuis la méthode HTTP GET. C’est une bien meilleure pratique que d’utiliser un HTTP POST pour toute requête qui change l’état sur le serveur. Mais même les sites web qui utilisent POST` pour les actions relatives au changement d’état sont vulnérables aux CSRF.

Supposons qu’example.com a amélioré sa fonctionnalité de déconnexion de façon à ce qu’ un bouton <form> soit requis via un POST sur l’URL example.com/logout. Plus précisement, le <form> de déconnexion inclu ce champ caché:

<input type="hidden" name="confirm" value="true" />

Ceci permet qu’un simple POST vers l’URL example.com/logout ne déconnectera pas l’utilisateur; Pour qu’un utilisateur se déconnecte, l’utilisateur doit faire une requête à example.com/logout via POST et envoyer la variable confirm POST avec une valeur à 'true'.

Ensuite, malgré cette sécurité supplémentaire, cet arrangement peut toujours être exploitée par CSRF - la page malicieuse à juste besoin de faire un peu plus de travail. Les attaquants peuvent créer un formulaire entier ciblant votre site, le masquer dans un <iframe> invisible, pour ensuite utiliser Javascript afin de valider ce formulaire automatiquement.

Prévenir les CSRF

Comment, alors, votre propre site peut se protéger de ces exploits ? La première étape est de s’assurer que toutes les requêtes GET sont libre d’effet de bord. De cette façon, si un site malicieux embarque une de vos page sous forme d’<iframe>, il n’y aura pas d’effet négatif.

Cela nous laisse les requêtes POST. La seconde étape consiste à donner à chaque <form> POST un champ caché dont la valeur est secrête et est générée à partir de l’ID de session de l’utilisateur. Ensuite, lors du traitement du formulaire côté serveur, il ne reste plus qu’à contrôler ce champ caché et à lever une erreur s’il n’est pas valide.

C’est exactement ce que fait la couche CSRF préventive, comme détaillé dans les sections qui suivent.

apnumber

Pour les nombres allant de 1 à 9, ce filtre renvoie la forme litérale du nombre. Sinon, il retourne le numéral. Ceci suit le style Associated Press.

Exemples:

• 1 devient «one».
• 2 devient «two».
• 10 devient «10».

Vous pouvez lui passer soit un entier ou une représentation d’un entier sous forme de chaîne de caractère.

intcomma

Ce filtre converti un entier en une chaîne contenant des virgules tous les trois chiffres.

Exemples:

• 4500 devient «4,500».
• 45000 devient «45,000».
• 450000 devient «450,000».
• 4500000 devient «4,500,000».

Vous pouvez passer soit un entier soit une représentation d’un entier sous forme de chaîne.

intword

Ce filtre converti un grand entier en une représentation textuelle familière. Il fonctionne mieux pour les nombres au-delà du million.

Exemples:

• 1000000 devient «1.0 million».
• 1200000 devient «1.2 million».
• 1200000000 devient «1.2 billion».

Les valeur au-delà du quadrillion (1,000,000,000,000,000) sont supportées.

Vous pouvez passer soit un entier soit une représentation d’un entier sous forme de chaîne.

ordinal

Ce filtre converti un entier en sont ordinal sous forme de chaîne.

Exemples:

• 1 devient «1st».
• 2 devient «2nd».
• 3 devient «3rd».

Vous pouvez passer soit un entier soit une représentation d’un entier sous forme de chaîne.