Ce document présente tous les composants intergiciels livrés avec Django. Pour plus d’informations sur la façon de les utiliser et sur la manière d’écrire ses propres intergiciels, consultez le guide d’utilisation des intergiciels.
Active le cache global du site. Quand il est actif, chaque page générée par Django est mise en cache pour une durée équivalente au réglage CACHE_MIDDLEWARE_SECONDS. Voir la documentation du cache.
Ajoute quelques commodités pour les perfectionnistes :
Interdit l’accès aux agents utilisateurs (navigateurs) mentionnés dans le réglage DISALLOWED_USER_AGENTS, qui devrait contenir une liste d’objets expression régulière compilés.
Effectue une réécriture d’URL sur la base des réglages APPEND_SLASH et PREPEND_WWW.
Si APPEND_SLASH vaut True et que l’URL initiale ne se termine pas par une barre oblique et que l’URL n’est pas trouvée dans les configuration d’URL, une nouvelle URL est formée en y ajoutant une barre oblique à la fin. Si la nouvelle URL est trouvée dans la configuration d’URL, Django redirige la requête vers cette URL. Sinon, l’URL de départ est traitée comme d’habitude.
Par exemple, foo.com/bar sera redirigée vers foo.com/bar/ s’il n’existe pas de motif d’URL valide correspondant à foo.com/bar mais qu’il existe un motif valide pour foo.com/bar/.
Si PREPEND_WWW vaut True, les URL ne commençant pas par « www. » seront redirigées vers la même URL commençant par « www. ».
Ces deux options visent à normaliser les URL. L’idée étant que chaque URL devrait exister sous une et une seule forme. Techniquement, une URL foo.com/bar est différente de foo.com/bar/ – un index de moteur de recherche les traiterait comme des URL distinctes – ce qui justifie la bonne pratique de normaliser les URL.
Gère les en-têtes ETags sur la base du réglage USE_ETAGS. Si USE_ETAGS vaut True, Django génère l’en-tête ETag pour chaque requête en calculant l’empreinte MD5 du contenu de la page, et il se chargera d’envoyer des réponses Not Modified le cas échéant.
Envoie des courriels de notification de lien brisé aux MANAGERS (voir Signalement d’erreurs).
Avertissement
Les chercheurs en sécurité ont récemment découvert que lorsque des techniques de compression (y compris avec GZipMiddleware) sont utilisés sur un site Web, le site s’expose à un certain nombre d’attaques potentielles. Ces approches peuvent être utilisées pour compromettre la protection de Django contre les attaques CSRF, entre autres choses. Avant d’utiliser GZipMiddleware pour votre site, vous devriez évaluer avec soin si vous êtes une cible possible de ces attaques. Si vous doutez d’une façon ou d’une autre à ce sujet, vous devriez éviter d’utiliser cet intergiciel. Pour plus de détails, consultez le document présentant la faille (PDF) et breachattack.com.
Compresse le contenu pour les navigateurs qui prennent en charge la compression GZip (tous les navigateurs modernes).
Cet intergiciel devrait être placé avant tout autre intergiciel qui a besoin de lire ou d’écrire le corps de la réponse afin que la compression puisse avoir lieu après.
Il ne compresse PAS le contenu si l’un des critères suivants est vrai :
La taille du corps du contenu est plus petite que 200 octets.
La réponse a déjà défini l’en-tête Content-Encoding.
La requête (le navigateur) n’a pas envoyé d’en-tête Accept-Encoding incluant gzip.
La requête provient d’Internet Explorer et l’en-tête Content-Type contient javascript ou commence par autre chose que text/. Nous faisons cette distinction pour éviter un bogue dans d’anciennes versions d’Internet Explorer qui n’effectuent pas de décompression pour certains types de contenus.
Vous pouvez appliquer la compression GZip pour des vues individuelles en utilisant le décorateur gzip_page().
Traite les opérations GET conditionnelles. Si la réponse possède un en-tête ETag ou Last-Modified et que la requête possède l’en-tête If-None-Match ou If-Modified-Since, la réponse est remplacée par HttpResponseNotModified.
Définit également les en-têtes de réponse Date et Content-Length.
Active le choix de la langue en fonction de données de la requête. Le contenu est alors personnalisé par utilisateur. Voir la documentation sur l’internationalisation.
Active la prise en charge des messages par session ou par cookie. Voir la documentation sur les messages.
Active la prise en charge des sessions. Voir la documentation sur les sessions.
Ajoute l’attribut user représentant l’utilisateur actuellement connecté à chaque objet HttpRequest entrant. Voir Authentification dans les requêtes Web.
Intergiciel permettant d’exploiter l’authentification fournie par le serveur Web. Voir Authentification avec REMOTE_USER pour les détails d’utilisation.
Ajoute la protection contre les attaques Cross Site Request Forgeries en ajoutant des champs de formulaires masqués aux formulaires POST et en contrôlant que les requêtes contiennent la valeur correcte. Voir la documentation concernant la protection contre les attaques Cross Site Request Forgery.
TransactionMiddleware est obsolète. La documentation sur les transactions contient des instructions de mise à niveau.
Relie les opérations de « commit » et de « rollback » de la base de données par défaut au cycle de requête/réponse. Si une fonction de vue s’exécute proprement, une opération « commit » est effectuée. Si elle échoue par une exception, c’est une opération de « rollback » qui sera effectuée.
La position de cet intergiciel dans la pile est importante : les modules d’intergiciel s’exécutant en dehors de l’influence de cet intergiciel utilisent la stratégie « commit après enregistrement », le comportement par défaut de Django. Les modules d’intergiciel sous son influence (apparaissant après dans la pile) seront placés sous le même contrôle transactionnel que les fonctions de vue.
Protection simple contre les attaques par détournement de clic au moyen de l’en-tête X-Frame-Options.
Jan 13, 2016