--- title: "Intergiciels (« middleware »)" version: 6.0 locale: fr source: https://docs.djangoproject.com/fr/6.0/ref/middleware/ canonical: https://djangodocs.dev/fr/6.0/ref/middleware/ --- # Intergiciels (« middleware ») 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](/fr/6.0/topics/http/middleware/). ## Intergiciels disponibles ### Intergiciel de cache #### `class UpdateCacheMiddleware` #### `class FetchFromCacheMiddleware` 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`](/fr/6.0/ref/settings/#std-setting-CACHE_MIDDLEWARE_SECONDS). Voir la [documentation du cache](/fr/6.0/topics/cache/). ### Intergiciel « common » #### `class CommonMiddleware` #### `response_redirect_class` La valeur par défaut est [`HttpResponsePermanentRedirect`](/fr/6.0/ref/request-response/#django.http.HttpResponsePermanentRedirect). Créez une sous-classe de `CommonMiddleware` et surchargez cet attribut pour personnaliser les redirections émises par l’intergiciel. Ajoute quelques commodités pour les perfectionnistes : - Interdit l’accès aux agents utilisateurs (navigateurs) mentionnés dans le réglage [`DISALLOWED_USER_AGENTS`](/fr/6.0/ref/settings/#std-setting-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`](/fr/6.0/ref/settings/#std-setting-APPEND_SLASH) et [`PREPEND_WWW`](/fr/6.0/ref/settings/#std-setting-PREPEND_WWW). Si [`APPEND_SLASH`](/fr/6.0/ref/settings/#std-setting-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`](/fr/6.0/ref/settings/#std-setting-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. Si nécessaire, des vues individuelles peuvent être exclues du comportement `APPEND_SLASH` en utilisant le décorateur [`no_append_slash()`](/fr/6.0/topics/http/decorators/#django.views.decorators.common.no_append_slash): ``` from django.views.decorators.common import no_append_slash @no_append_slash def sensitive_fbv(request, *args, **kwargs): """View to be excluded from APPEND_SLASH.""" return HttpResponse() ``` - Définit l’en-tête `Content-Length` pour les réponses qui ne sont pas de type flux. #### `class BrokenLinkEmailsMiddleware` - Envoie des courriels de notification de lien brisé aux [`MANAGERS`](/fr/6.0/ref/settings/#std-setting-MANAGERS) (voir [Gestion du signalement des erreurs](/fr/6.0/howto/error-reporting/)). ### Intergiciel GZip #### `class GZipMiddleware` #### `max_random_bytes` Vaut 100 par défaut. Créer une sous-classe de `GZipMiddleware` et surchargez l’attribut pour modifier le nombre maximum d’octets aléatoires inclus dans les réponses compressées. > **Note** > > Des chercheurs en sécurité ont révélé que lorsque des techniques de compression (y compris `GZipMiddleware`) sont utilisées par un site web, le site peut être exposé à un certain nombre d’attaques. > > Pour limiter ces attaques, Django implémente une technique appelée *Heal The Breach (HTB)*. Elle ajoute jusqu’à 100 octets aléatoires (voir [`max_random_bytes`](#django.middleware.gzip.GZipMiddleware.max_random_bytes)) à chaque réponse pour réduire l’efficacité de ces attaques. > > Pour plus de détails, consultez le [document BREACH (PDF)](https://www.breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf), [breachattack.com](https://www.breachattack.com/) et le [document Heal The Breach (HTB)](https://ieeexplore.ieee.org/document/9754554). L’intergiciel `django.middleware.gzip.GZipMiddleware` 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`. Si la réponse possède un en-tête `ETag`, l’ETag est rendu faible pour se conformer à [**RFC 9110 Section 8.8.1**](https://datatracker.ietf.org/doc/html/rfc9110.html#section-8.8.1). Vous pouvez appliquer la compression GZip pour des vues individuelles en utilisant le décorateur [`gzip_page()`](/fr/6.0/topics/http/decorators/#django.views.decorators.gzip.gzip_page). ### Intergiciel GET conditionnel #### `class ConditionalGetMiddleware` Traite les opérations GET conditionnelles. Si la réponse ne possède pas d’en-tête `ETag`, l’intergiciel en crée un si nécessaire. 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`](/fr/6.0/ref/request-response/#django.http.HttpResponseNotModified). Vous pouvez gérer les opérations GET conditionnelles avec des vues individuelles en utilisant le décorateur `conditional_page()`. ### Intergiciel de locale #### `class LocaleMiddleware` #### `response_redirect_class` La valeur par défaut est [`HttpResponseRedirect`](/fr/6.0/ref/request-response/#django.http.HttpResponseRedirect). Créez une sous-classe de `LocaleMiddleware` et surchargez cet attribut pour personnaliser les redirections émises par l’intergiciel. 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](/fr/6.0/topics/i18n/translation/). ### Intergiciel de messages #### `class MessageMiddleware` Active la prise en charge des messages par session ou par cookie. Voir la [documentation sur les messages](/fr/6.0/ref/contrib/messages/). ### Intergiciel de sécurité > **Warning** > > Si votre situation de déploiement le permet, il est généralement préférable de déléguer au serveur web frontal la fonctionnalité fournie par l’intergiciel `SecurityMiddleware`. De cette façon, si certaines requêtes ne sont pas fournies par Django (comme des fichiers statiques ou des fichiers envoyés par les utilisateurs), elles bénéficieront de la même protection que les requêtes servies par l’application Django. #### `class SecurityMiddleware` L’intergiciel `django.middleware.security.SecurityMiddleware` fournit plusieurs améliorations de sécurité au cycle de requête/réponse. Chaque amélioration peut être activée ou désactivée indépendamment par un réglage. - [`SECURE_CONTENT_TYPE_NOSNIFF`](/fr/6.0/ref/settings/#std-setting-SECURE_CONTENT_TYPE_NOSNIFF) - [`SECURE_CROSS_ORIGIN_OPENER_POLICY`](/fr/6.0/ref/settings/#std-setting-SECURE_CROSS_ORIGIN_OPENER_POLICY) - [`SECURE_HSTS_INCLUDE_SUBDOMAINS`](/fr/6.0/ref/settings/#std-setting-SECURE_HSTS_INCLUDE_SUBDOMAINS) - [`SECURE_HSTS_PRELOAD`](/fr/6.0/ref/settings/#std-setting-SECURE_HSTS_PRELOAD) - [`SECURE_HSTS_SECONDS`](/fr/6.0/ref/settings/#std-setting-SECURE_HSTS_SECONDS) - [`SECURE_REDIRECT_EXEMPT`](/fr/6.0/ref/settings/#std-setting-SECURE_REDIRECT_EXEMPT) - [`SECURE_REFERRER_POLICY`](/fr/6.0/ref/settings/#std-setting-SECURE_REFERRER_POLICY) - [`SECURE_SSL_HOST`](/fr/6.0/ref/settings/#std-setting-SECURE_SSL_HOST) - [`SECURE_SSL_REDIRECT`](/fr/6.0/ref/settings/#std-setting-SECURE_SSL_REDIRECT) #### Sécurité de transport HTTP stricte (HSTS) Pour les sites qui ne devraient pouvoir être accédés que par HTTPS, vous pouvez demander aux navigateurs modernes de refuser les connexions à votre nom de domaine si la connexion n’est pas sécurisée (pour une certaine période de temps) en définissant l”[en-tête « Strict-Transport-Security »](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security). Cela réduit l’exposition à certaines attaques de type « homme du milieu » (MITM) par détournement SSL. `SecurityMiddleware` définit cet en-tête pour vous sur toutes les réponses HTTPS si vous définissez le réglage [`SECURE_HSTS_SECONDS`](/fr/6.0/ref/settings/#std-setting-SECURE_HSTS_SECONDS) à une valeur entière différente de zéro. Lors de l’activation de HSTS, il est recommandé d’utiliser d’abord une faible valeur pour tester, par exemple [`SECURE_HSTS_SECONDS = 3600`](/fr/6.0/ref/settings/#std-setting-SECURE_HSTS_SECONDS) pour une heure. Chaque fois qu’un navigateur web lit l’en-tête HSTS pour votre site, il refusera de communiquer de manière non sécurisée (par HTTP) avec votre domaine pour la durée de temps indiquée. Après avoir obtenu confirmation que toutes les ressources de votre site sont servies de manière sécurisée (c’est-à-dire que HSTS ne casse rien du tout), il est alors possible et souhaité d’augmenter cette valeur afin que les visiteurs occasionnels soient protégés (il est fréquent de voir 31536000 secondes, c’est-à-dire 1 an). De plus, si vous définissez le réglage [`SECURE_HSTS_INCLUDE_SUBDOMAINS`](/fr/6.0/ref/settings/#std-setting-SECURE_HSTS_INCLUDE_SUBDOMAINS) à `True`, `SecurityMiddleware` ajoute la directive `includeSubDomains` à l’en-tête `Strict-Transport-Security`. C’est recommandé (pour autant que tous les sous-domaines soient servis exclusivement par HTTPS), sinon votre site pourrait rester vulnérable au travers d’une connexion non sécurisée à un sous-domaine. Si vous souhaitez soumettre votre site à la [liste de préchargement du navigateur](https://hstspreload.org/), définissez le réglage [`SECURE_HSTS_PRELOAD`](/fr/6.0/ref/settings/#std-setting-SECURE_HSTS_PRELOAD) à `True`. Cela ajoute la directive `preload` à l’en-tête `Strict-Transport-Security`. > **Warning** > > La politique HSTS s’applique à un domaine entier, pas seulement pour l’URL de la réponse pour laquelle vous définissez cet en-tête. Il ne faut donc l’utiliser que si tout le domaine est servi exclusivement par HTTPS. > > Les navigateurs respectant scrupuleusement l’en-tête HSTS refuseront aux utilisateurs de passer outre les avertissements et de se connecter à un site avec un certificat SSL expiré, auto-signé ou non valide pour toute autre raison. Si vous utilisez HSTS, assurez-vous que vos certificats sont en bon état et qu’ils le restent ! > **Note** > > Si votre déploiement se trouve derrière un répartiteur de charge ou un serveur mandataire inverse, et que l’en-tête `Strict-Transport-Security` n’est pas ajouté à vos réponses, il est possible que Django ne détecte pas qu’il fonctionne sur une connexion sécurisée ; il faut alors définir le réglage [`SECURE_PROXY_SSL_HEADER`](/fr/6.0/ref/settings/#std-setting-SECURE_PROXY_SSL_HEADER). #### Politique de référencement Les navigateurs utilisent [l’en-tête Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer) comme manière d’envoyer aux sites l’information sur la provenance des utilisateurs. Lorsqu’on clique sur un lien, le navigateur envoie l’URL complète de la page contenant le lien en tant que référent. Bien que cela puisse être utile dans certains cas, comme pour savoir qui place des liens vers votre site, cela pose des problèmes de confidentialité en informant un site que l’utilisateur vient de visiter un autre site. Certains navigateurs ont la capacité d’accepter des indices pour savoir s’ils doivent inclure ou non l’en-tête HTTP `Referer` lorsque quelqu’un clique sur un lien ; cette astuce est transmise par [l’en-tête Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy). Cet en-tête peut suggérer trois différents comportements aux navigateurs : - URL complète : envoi de l’URL complète dans l’en-tête `Referer`. Par exemple, si quelqu’un visite `https://example.com/page.html`, l’en-tête `Referer` contiendra `"https://example.com/page.html"`. - Origine uniquement : envoi uniquement de l’origine dans le référent. L’origine est composée du protocole, de l’hôte et du numéro de port (facultatif). Par exemple, si quelqu’un visite `https://example.com/page.html`, l’origine sera `https://example.com/`. - Aucun référent : l’en-tête `Referer` ne sera pas envoyée du tout. Il y a deux types de conditions que cet en-tête peut signaler au navigateur : - Same-origin versus cross-origin : un lien de `https://example.com/1.html` vers `https://example.com/2.html` est de même origine (same-origin). Une lien de `https://example.com/page.html` vers `https://not.example.com/page.html` est d’origine croisée (cross-origin). - Rétrogradation (downgrade) de protocole : une rétrogradation survient si la page contenant le lien est servie en HTTPS mais que la page de destination n’est pas servie en HTTPS. > **Warning** > > Quand votre site est servi par HTTPS, [la protection CSRF de Django](/fr/6.0/ref/csrf/#how-csrf-works) exige la présence de l’en-tête `Referer`, ce qui fait qu’une désactivation complète de l’en-tête va empêcher la protection CSRF. Pour obtenir la plupart des bénéfices de la désactivation des en-têtes `Referer` tout en conservant la protection CSRF, nous conseillons de n’activer que les référents de même origine. `SecurityMiddleware` peut définir l’en-tête `Referrer-Policy` pour vous, sur la base du réglage [`SECURE_REFERRER_POLICY`](/fr/6.0/ref/settings/#std-setting-SECURE_REFERRER_POLICY) (notez l’orthographe : les navigateurs envoient un en-tête `Referer` quand on clique sur un lien, mais l’en-tête indiquant au navigateur de le faire est orthographié `Referrer-Policy`). Les valeurs valables pour ce réglage sont : **`no-referrer`** Indique au navigateur de ne pas envoyer de référent pour les liens sur lesquels on clique sur ce site. **`no-referrer-when-downgrade`** Indique au navigateur d’envoyer une URL complète comme référent, mais seulement si aucune rétrogradation de protocole n’a lieu. **`origin`** Indique au navigateur de n’envoyer que l’origine comme référent, pas l’URL complète. **`origin-when-cross-origin`** Indique au navigateur d’envoyer une URL complète comme référent pour les liens de même origine, mais seulement l’origine pour les liens d’origine croisée. `same-origin` indique au navigateur d’envoyer une URL complète, mais seulement pour les liens de même origine. Aucun référent n’est envoyé pour les liens d’origine croisée. `strict-origin` indique au navigateur de n’envoyer que l’origine comme référent, pas l’URL complète, et de ne pas envoyer de référent lorsqu’une rétrogradation de protocole survient. **`strict-origin-when-cross-origin`** Indique au navigateur d’envoyer l’URL complète lorsque le lien est de même origine et qu’aucune rétrogradation de protocole ne survient ; envoyer uniquement l’origine lorsque le lien est d’origine croisée et ne rien envoyer du tout si une rétrogradation de protocole survient. **`unsafe-url`** Indique au navigateur de toujours envoyer une URL complète comme référent. > **Valeurs de politique inconnues** > > Il est possible que certaines valeurs de politique soient [inconnues](https://w3c.github.io/webappsec-referrer-policy/#unknown-policy-values) pour un agent utilisateur. Il est de ce fait autorisé d’indiquer plusieurs valeurs de politique pour fournir une valeur de repli. La priorité est donnée à la dernière valeur fournie qui est comprise. Pour prendre cela en charge, un objet itérable ou une chaîne séparée par des virgules peut être utilisée dans [`SECURE_REFERRER_POLICY`](/fr/6.0/ref/settings/#std-setting-SECURE_REFERRER_POLICY). #### Politique d’ouverture d’origine croisée Certains navigateurs ont la capacité d’isoler les fenêtres de premier niveau des autres documents en les plaçant dans un groupe de contexte de navigation séparé basé sur la valeur de l’en-tête [Cross-Origin Opener Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP). Si un document isolé de cette manière ouvre une fenêtre popup d’origine croisée, la propriété `window.opener` de cette fenêtre vaudra `null`. L’isolation des fenêtres avec COOP est une protection défensive en profondeur contre les attaques d’origine croisée, particulièrement celles comme Spectre qui permettent d’exfiltrer des données chargées dans un contexte de navigation partagé. `SecurityMiddleware` peut définir l’en-tête `Cross-Origin-Opener-Policy` pour vous, basé sur le réglage [`SECURE_CROSS_ORIGIN_OPENER_POLICY`](/fr/6.0/ref/settings/#std-setting-SECURE_CROSS_ORIGIN_OPENER_POLICY). Les valeurs valides pour ce réglage sont : **`same-origin`** Isole le contexte de navigation exclusivement pour les documents de même origine. Les documents d’origine croisée ne sont pas chargés dans le même contexte de navigation. Il s’agit de l’option par défaut et de la plus sûre. **`same-origin-allow-popups`** Isole le contexte de navigation aux documents de même origine ou à ceux qui ne définissent pas l’en-tête COOP ou qui se distancient de l’isolation en définissant un en-tête COOP à `unsafe-none`. **`unsafe-none`** Permet au document d’être ajouté au groupe de contexte de navigation de sa fenêtre d’origine sauf si cette dernière possède elle-même un en-tête COOP à la valeur `same-origin` ou `same-origin-allow-popups`. #### `X-Content-Type-Options: nosniff` Certains navigateurs essaient de deviner les types de contenu des ressources qu’ils appellent, sans tenir compte de l’en-tête `Content-Type`. Bien que cela puisse aider à afficher des sites dont les serveurs sont mal configurés, cela peut aussi poser un risque de sécurité. Si votre site sert des fichiers que des utilisateurs ont envoyés, un utilisateur mal intentionné pourrait envoyer un fichier spécialement écrit pour qu’il soit interprété comme du HTML ou du JavaScript par le navigateur alors que vous vous attendiez à ce que son contenu soit inoffensif. Pour empêcher le navigateur de deviner le type de contenu et le forcer à toujours utiliser le type indiqué dans l’en-tête `Content-Type`, vous pouvez définir l’en-tête [X-Content-Type-Options: nosniff](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options). `SecurityMiddleware` s’en charge pour toutes les réponses si le réglage [`SECURE_CONTENT_TYPE_NOSNIFF`](/fr/6.0/ref/settings/#std-setting-SECURE_CONTENT_TYPE_NOSNIFF) est défini à `True`. Notez que dans la plupart des situations de déploiement où Django n’est pas impliqué dans le service de fichiers envoyés par les utilisateurs, ce réglage ne va pas aider. Par exemple, si le contenu de [`MEDIA_URL`](/fr/6.0/ref/settings/#std-setting-MEDIA_URL) est directement servi par le serveur web frontal (nginx, Apache, etc.), c’est par ce dernier que l’en-tête doit être défini. D’un autre côté, si vous utilisez Django pour s’occuper de choses comme exiger une autorisation avant de pouvoir télécharger des fichiers et que vous n’êtes pas en mesure de faire définir cet en-tête par le serveur web, ce réglage sera utile. #### Redirection SSL Si votre site offre à la fois des connexions HTTP et HTTPS, la plupart des utilisateurs obtiendront une connexion non sécurisée par défaut. Pour une meilleure sécurité, vous devriez rediriger toutes les connexions HTTP vers HTTPS. Si vous définissez le réglage [`SECURE_SSL_REDIRECT`](/fr/6.0/ref/settings/#std-setting-SECURE_SSL_REDIRECT) à `True`, `SecurityMiddleware` va rediriger de manière permanente (HTTP 301) toutes les connexions HTTP vers HTTPS. > **Note** > > Pour des raisons de performance, il est préférable de procéder à ces redirections en dehors de Django, dans une répartiteur de charge frontal ou un serveur mandataire inverse tel que [nginx](https://nginx.org/). [`SECURE_SSL_REDIRECT`](/fr/6.0/ref/settings/#std-setting-SECURE_SSL_REDIRECT) est prévu pour des situations de déploiement où ce scénario n’est pas envisageable. Si le réglage [`SECURE_SSL_HOST`](/fr/6.0/ref/settings/#std-setting-SECURE_SSL_HOST) possède une valeur, toutes les redirections seront envoyées vers cet hôte au lieu de l’hôte d’origine de la requête. Si certaines pages de votre site doivent rester disponibles par HTTP sans être redirigées vers HTTPS, vous pouvez ajouter des expressions régulières correspondantes à ces URL dans le réglage [`SECURE_REDIRECT_EXEMPT`](/fr/6.0/ref/settings/#std-setting-SECURE_REDIRECT_EXEMPT) (sous forme de liste). > **Note** > > Si votre déploiement se trouve derrière un répartiteur de charge ou un serveur mandataire inverse, et que Django ne semble pas pouvoir détecter si une requête est déjà sécurisée ou non, il peut alors être nécessaire de définir le réglage [`SECURE_PROXY_SSL_HEADER`](/fr/6.0/ref/settings/#std-setting-SECURE_PROXY_SSL_HEADER). ### Intergiciel de session #### `class SessionMiddleware` Active la prise en charge des sessions. Voir la [documentation sur les sessions](/fr/6.0/topics/http/sessions/). ### Intergiciel de site #### `class CurrentSiteMiddleware` Ajoute l’attribut `site` représentant le site en cours à chaque objet `HttpRequest` entrant. Voir la [documentation sur les sites](/fr/6.0/ref/contrib/sites/#site-middleware). ### Intergiciel d’authentification #### `class AuthenticationMiddleware` Ajoute l’attribut `user` représentant l’utilisateur actuellement connecté à chaque objet `HttpRequest` entrant. Voir [Authentification dans les requêtes web](/fr/6.0/topics/auth/default/#auth-web-requests). #### `class LoginRequiredMiddleware` Pour personnaliser le comportement en cas de requêtes non authentifiées, créez une sous-classe de l’intergiciel et surchargez les attributs et méthodes suivantes. #### `redirect_field_name` Sa valeur par défaut est `"next"`. #### `get_login_url()` Renvoie l’URL vers laquelle seront redirigées les requêtes non authentifiées. Cette méthode renvoie soit la valeur `login_url` éventuellement définie par le décorateur [`login_required()`](/fr/6.0/topics/auth/default/#django.contrib.auth.decorators.login_required) (si pas `None`) ou [`settings.LOGIN_URL`](/fr/6.0/ref/settings/#std-setting-LOGIN_URL). #### `get_redirect_field_name()` Renvoie le nom du paramètre de requête qui contient l’URL vers laquelle l’utilisateur sera redirigé à la suite d’une connexion réussie. Cette méthode renvoie soit un éventuel attribut `redirect_field_name` défini sur la vue par le décorateur [`login_required()`](/fr/6.0/topics/auth/default/#django.contrib.auth.decorators.login_required) (si pas `None`) ou [`redirect_field_name`](#django.contrib.auth.middleware.LoginRequiredMiddleware.redirect_field_name). Si la valeur renvoyée est `None`, aucun paramètre de requête ne sera ajouté. Redirige toutes les requêtes non authentifiées ver une page de connexion, sauf pour les vues exclues par [`login_not_required()`](/fr/6.0/topics/auth/default/#django.contrib.auth.decorators.login_not_required). La page de connexion par défaut est [`settings.LOGIN_URL`](/fr/6.0/ref/settings/#std-setting-LOGIN_URL), mais il est possible de la personnaliser. Activez cet intergiciel en l’ajoutant dans le réglage [`MIDDLEWARE`](/fr/6.0/ref/settings/#std-setting-MIDDLEWARE) **après** [`AuthenticationMiddleware`](#django.contrib.auth.middleware.AuthenticationMiddleware): ``` MIDDLEWARE = [ "...", "django.contrib.auth.middleware.AuthenticationMiddleware", "django.contrib.auth.middleware.LoginRequiredMiddleware", "...", ] ``` Pour rendre une vue publique, autorisant les requêtes non authentifiées, utilisez le décorateur [`login_not_required()`](/fr/6.0/topics/auth/default/#django.contrib.auth.decorators.login_not_required). Par exemple : ``` from django.contrib.auth.decorators import login_not_required @login_not_required def contact_us(request): ... ``` Il est possible de personnaliser l’URL de connexion ou le nom du champ de redirection pour les vues exigeant l’authentification avec le décorateur [`login_required()`](/fr/6.0/topics/auth/default/#django.contrib.auth.decorators.login_required) pour définir respectivement `login_url` ou `redirect_field_name`. Par exemple : ``` from django.contrib.auth.decorators import login_required from django.utils.decorators import method_decorator from django.views.generic import View @login_required(login_url="/books/login/", redirect_field_name="redirect_to") def book_dashboard(request): ... @method_decorator( login_required(login_url="/books/login/", redirect_field_name="redirect_to"), name="dispatch", ) class BookMetrics(View): pass ``` > **La vue de connexion ne doit pas nécessiter elle-même une connexion.** > > Pour empêcher des redirections infinies, vérifiez que la vue de connexion [autorise les requêtes non authentifiées](/fr/6.0/topics/auth/default/#disable-login-required-middleware-for-views). #### `class RemoteUserMiddleware` Intergiciel permettant d’exploiter l’authentification fournie par le serveur web. Voir [Comment authentifier avec REMOTE\_USER](/fr/6.0/howto/auth-remote-user/) pour les détails d’utilisation, y compris des considérations de sécurité. #### `class PersistentRemoteUserMiddleware` Intergiciel permettant d’exploiter l’authentification fournie par le serveur web lorsqu’elle n’est activée que sur la page de connexion. Voir [Utilisation de REMOTE\_USER uniquement pour les pages de connexion](/fr/6.0/howto/auth-remote-user/#persistent-remote-user-middleware-howto) pour les détails d’utilisation, y compris des considérations de sécurité. ### Intergiciel de protection CSRF #### `class CsrfViewMiddleware` 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](/fr/6.0/ref/csrf/). Vous pouvez ajouter la protection CSRF à des vues individuelles en utilisant le décorateur [`csrf_protect()`](/fr/6.0/ref/csrf/#django.views.decorators.csrf.csrf_protect). ### Intergiciel `X-Frame-Options` #### `class XFrameOptionsMiddleware` Protection simple contre les [attaques par détournement de clic au moyen de l’en-tête X-Frame-Options](/fr/6.0/ref/clickjacking/). ### Intergiciel de la politique de sécurité de contenu (CSP) #### `class ContentSecurityPolicyMiddleware` > **New in Django 6.0** Adds support for Content Security Policy (CSP), which helps mitigate risks such as Cross-Site Scripting (XSS) and data injection attacks by controlling the sources of content that can be loaded in the browser. See the [Aperçu](/fr/6.0/ref/csp/#csp-overview) documentation for details on configuring policies. This middleware sets the following headers on the response depending on the available settings: - `Content-Security-Policy`, based on [`SECURE_CSP`](/fr/6.0/ref/settings/#std-setting-SECURE_CSP). - `Content-Security-Policy-Report-Only`, based on [`SECURE_CSP_REPORT_ONLY`](/fr/6.0/ref/settings/#std-setting-SECURE_CSP_REPORT_ONLY). ## Ordre des intergiciels Voici quelques indications au sujet de l’ordre des diverses classes d’intergiciel Django : 1. [`SecurityMiddleware`](#django.middleware.security.SecurityMiddleware) Il devrait se trouver assez haut dans la liste si vous prévoyez d’activer la redirection SSL car cela évite de passer par plusieurs autres intergiciels inutiles. 2. [`UpdateCacheMiddleware`](#django.middleware.cache.UpdateCacheMiddleware) Avant ceux qui modifient l’en-tête `Vary` (`SessionMiddleware`, `GZipMiddleware`, `LocaleMiddleware`). 3. [`GZipMiddleware`](#django.middleware.gzip.GZipMiddleware) Avant tout intergiciel susceptible de modifier ou d’utiliser le corps de la réponse. Après `UpdateCacheMiddleware`: modifie l’en-tête `Vary`. 4. [`SessionMiddleware`](#django.contrib.sessions.middleware.SessionMiddleware) Avant tout intergiciel pouvant générer une exception déclenchant une vue d’erreur (comme par exemple [`PermissionDenied`](/fr/6.0/ref/exceptions/#django.core.exceptions.PermissionDenied)) dans le cas où vous utilisez [`CSRF_USE_SESSIONS`](/fr/6.0/ref/settings/#std-setting-CSRF_USE_SESSIONS). Après `UpdateCacheMiddleware`: modifie l’en-tête `Vary`. 5. [`ConditionalGetMiddleware`](#django.middleware.http.ConditionalGetMiddleware) Avant tout intergiciel pouvant modifier la réponse (définit l’en-tête `ETag`). Après `GZipMiddleware` afin qu’il ne calcule pas d’en-tête `ETag` pour du contenu compressé gzip. 6. [`LocaleMiddleware`](#django.middleware.locale.LocaleMiddleware) Doit être dans les premiers, après `SessionMiddleware` (utilise les données de sessions) et `UpdateCacheMiddleware` (modifie l’en-tête `Vary`). 7. [`CommonMiddleware`](#django.middleware.common.CommonMiddleware) Avant tout intergiciel qui pourrait modifier la réponse (il définit l’en-tête `Content-Length`). Un intergiciel apparaissant avant `CommonMiddleware` et modifiant la réponse doit réinitialiser `Content-Length`. Dans les tout premiers : il redirige lorsque [`APPEND_SLASH`](/fr/6.0/ref/settings/#std-setting-APPEND_SLASH) ou [`PREPEND_WWW`](/fr/6.0/ref/settings/#std-setting-PREPEND_WWW) valent `True`. Après `SessionMiddleware` si vous utilisez [`CSRF_USE_SESSIONS`](/fr/6.0/ref/settings/#std-setting-CSRF_USE_SESSIONS). 8. [`CsrfViewMiddleware`](#django.middleware.csrf.CsrfViewMiddleware) Avant tout intergiciel comptant sur le fait que des attaques CSRF ont déjà été contrées. Avant [`RemoteUserMiddleware`](#django.contrib.auth.middleware.RemoteUserMiddleware) ou tout autre intergiciel d’authentification qui pourrait effectuer une connexion et ainsi activer la rotation du jeton CSRF, avant d’appeler la suite de la chaîne d’intergiciels. Après `SessionMiddleware` si vous utilisez [`CSRF_USE_SESSIONS`](/fr/6.0/ref/settings/#std-setting-CSRF_USE_SESSIONS). 9. [`AuthenticationMiddleware`](#django.contrib.auth.middleware.AuthenticationMiddleware) Après `SessionMiddleware`: utilise le stockage des sessions. 10. [`LoginRequiredMiddleware`](#django.contrib.auth.middleware.LoginRequiredMiddleware) Après `AuthenticationMiddleware`: utilise l’objet `user`. 11. [`MessageMiddleware`](#django.contrib.messages.middleware.MessageMiddleware) Après `SessionMiddleware`: peut utiliser le stockage basé sur les sessions. 12. [`FetchFromCacheMiddleware`](#django.middleware.cache.FetchFromCacheMiddleware) Après tout intergiciel qui modifie l’en-tête `Vary`: cet en-tête est utilisé pour choisir une valeur pour la clé de hachage du cache. 13. [`ContentSecurityPolicyMiddleware`](#django.middleware.csp.ContentSecurityPolicyMiddleware) Can be placed near the bottom, but ensure any middleware that accesses [csp\_nonce](/fr/6.0/ref/csp/#csp-nonce) is positioned after it, so the nonce is properly included in the response header. 14. [`FlatpageFallbackMiddleware`](/fr/6.0/ref/contrib/flatpages/#django.contrib.flatpages.middleware.FlatpageFallbackMiddleware) Devrait se situer dans les derniers car c’est un type d’intergiciel de dernier recours. 15. [`RedirectFallbackMiddleware`](/fr/6.0/ref/contrib/redirects/#django.contrib.redirects.middleware.RedirectFallbackMiddleware) Devrait se situer dans les derniers car c’est un type d’intergiciel de dernier recours.