{"title":"Intergiciels (« Middleware »)","version":"1.9","locale":"fr","docname":"topics/http/middleware","url":"/fr/1.9/topics/http/middleware/","canonical":"https://djangodocs.dev/fr/1.9/topics/http/middleware/","summary":"Les intergiciels représentent un système de points d’entrée dans le traitement des requêtes et des réponses de Django. C’est un système de greffons léger et de bas…","html":"
Les intergiciels représentent un système de points d’entrée dans le traitement des requêtes et des réponses de Django. C’est un système de greffons léger et de bas niveau pour modifier de façon globale les entrées et sorties HTTP de Django.
\n
Chaque composant d’intergiciel est responsable d’effectuer une tâche spécifique. Par exemple, Django contient un intergiciel, AuthenticationMiddleware, qui associe les utilisateurs aux requêtes et aux sessions.
\n
Ce document explique comment fonctionnent les intergiciels, la manière de les activer et d’écrire vos propres intergiciels. Django est livré avec quelques intergiciels intégrés qu’il est possible d’utiliser tels quels. Ils sont documentés dans la référence des intergiciels intégrés.
Pour activer un intergiciel, ajoutez son chemin dans la liste MIDDLEWARE_CLASSES de vos réglages Django.
\n
Dans MIDDLEWARE_CLASSES, chaque intergiciel est représenté par une chaîne : le chemin Python complet vers le nom de la classe d’intergiciel. Par exemple, voici la valeur par défaut créée par django-adminstartproject:
Une installation de Django n’a pas nécessairement des intergiciels, MIDDLEWARE_CLASSES pouvant très bien être vide si vous le souhaitez, mais il est fortement recommandé d’utiliser au moins CommonMiddleware.
\n
L’ordre dans MIDDLEWARE_CLASSES a son importance car un intergiciel peut dépendre d’un autre. Par exemple, AuthenticationMiddleware stocke l’utilisateur non authentifié dans la session ; il doit donc être exécuté après SessionMiddleware. Voir Ordre des intergiciels pour d’autres indications utiles concernant l’ordre des classes d’intergiciel de Django.
Durant la phase de requête, avant d’appeler la vue, Django applique les intergiciels dans l’ordre où ils sont définis dans MIDDLEWARE_CLASSES, de haut en bas. Deux points d’entrée sont disponibles :
Durant la phase de réponse, après avoir appelé la vue, Django applique les intergiciels dans l’ordre inverse de leur définition, de bas en haut. Trois points d’entrée sont disponibles :
process_request() est appelée pour chaque requête, avant que Django ne décide quelle vue exécuter.
\n
Elle doit renvoyer soit None, soit un objet HttpResponse. Si elle renvoie None, Django continue le traitement de la requête, en appliquant d’éventuels autres intergiciels process_request(), puis les intergiciels process_view() et pour terminer exécute la vue appropriée. Si elle renvoie un objet HttpResponse, Django n’applique plus aucun intergiciel de requête, de vue ou d’exception, ni la vue correspondante ; il va simplement appliquer les intergiciels de réponse à cet objet HttpResponse et renvoyer le résultat.
request est un objet HttpRequest. view_func et la fonction python que Django s’apprête à utiliser (il s’agit bien de l’objet fonction, pas du nom textuel de la fonction). view_args est une liste de paramètres positionnels qui seront transmis à la vue, et view_kwargs est un dictionnaire de paramètres nommés qui seront transmis à la vue. Ni view_args ni view_kwargs ne comprennent le premier paramètre de la vue (request).
\n
process_view() est appelée juste avant que Django n’appelle la vue.
\n
Elle doit renvoyer soit None, soit un objet HttpResponse. Si elle renvoie None, Django continue le traitement de la requête, en appliquant d’éventuels autres intergiciels process_view(), puis exécute la vue appropriée. Si elle renvoie un objet HttpResponse, Django n’applique plus aucun intergiciel de vue ou d’exception, ni la vue correspondante ; il va simplement appliquer les intergiciels de réponse à cet objet HttpResponse et renvoyer le résultat.
request est un objet HttpRequest. response est l’objet TemplateResponse (ou équivalent) renvoyé par une vue Django ou par un intergiciel.
\n
process_template_response() est appelée juste après la fin de l’exécution de la vue, pour autant que l’instance réponse possède une méthode render(), ce qui laisse penser qu’il s’agit d’un objet TemplateResponse ou d’un équivalent.
\n
Elle doit renvoyer un objet réponse qui implémente une méthode render. Elle peut modifier la réponse donnée en changeant response.template_name et response.context_data, ou elle peut créer et renvoyer une toute nouvelle classe TemplateResponse ou un équivalent.
\n
Il n’est pas nécessaire d’effectuer explicitement le rendu des réponses, celles-ci étant automatiquement « rendues » après que tous les intergiciels de réponse ont été appelés.
\n
Les intergiciels sont exécutés dans l’ordre inverse lors de la phase de réponse, ce qui inclut process_template_response().
Au contraire des méthodes process_request() et process_view(), la méthode process_response() est toujours appelée, même si les méthodes process_request() et process_view() de la même classe d’intergiciel ont été court-circuitées (parce qu’une méthode d’intergiciel précédente a renvoyé une réponse HttpResponse). En particulier, ceci implique que votre méthode process_response() ne peut pas compter sur une configuration créée dans process_request().
\n
Pour terminer, rappelez-vous que durant la phase de réponse, les intergiciels sont appliqués dans l’ordre inverse, de bas en haut. Cela signifie que les classes définies à la fin de MIDDLEWARE_CLASSES sont exécutées en premier.
Au contraire de HttpResponse, StreamingHttpResponse ne possède pas d’attribut content. En conséquence, les intergiciels ne peuvent plus compter sur le fait que toutes les réponses possèdent un attribut content. S’ils ont besoin d’accéder au contenu, ils doivent savoir s’ils ont affaire avec une réponse de type flux (streaming) et ajuster leur comportement en fonction de cela :
request est un objet HttpRequest. exception est un objet Exception généré par la fonction de vue.
\n
Django appelle process_exception() lorsqu’une vue génère une exception. process_exception() doit renvoyer None ou un objet HttpResponse. Si elle renvoie un objet HttpResponse, les intergiciels de réponse par gabarit et de réponse sont appliqués, et la réponse résultante sera renvoyée au navigateur. Sinon, la gestion par défaut des exceptions intervient.
\n
Encore une fois, les intergiciels sont exécutés dans l’ordre inverse lors de la phase de réponse, ce qui comprend process_exception. Si un intergiciel d’exception renvoie une réponse, les classes d’intergiciels situées au-dessus ne seront pas du tout appelées.
La plupart des classes d’intergiciels ne nécessitent pas d’initialisation dans la mesure où elles sont essentiellement des conteneurs pour les méthodes process_*. Si vous avez besoin d’une notion d’état global, il est possible d’utiliser __init__ pour cela. Cependant, gardez à l’esprit ces restrictions :
\n
\n
Django initialise les intergiciels sans paramètre, il n’est donc pas possible de définir des paramètres obligatoires à __init__.
\n
Contrairement aux méthodes process_* qui sont appelées une fois par requête, __init__ n’est appelée qu”une seule fois, lorsque le serveur Web répond à la première requête.
Il est parfois utile de déterminer au moment de l’exécution si un intergiciel doit être utilisé. Dans ces cas, la méthode __init__ de l’intergiciel peut générer l’exception django.core.exceptions.MiddlewareNotUsed. Django se charge alors d’enlever cet intergiciel du processus des intergiciels et un message de débogage est journalisé vers django.request lorsque DEBUG est défini à True.
Les classes d’intergiciels n’ont aucune obligation d’héritage.
\n
Une classe d’intergiciel peut se trouver n’importe où dans le chemin Python. Tout ce que Django demande, c’est que le réglage MIDDLEWARE_CLASSES contienne le chemin de l’intergiciel.
Si vous écrivez un composant intergiciel que vous pensez susceptible d’être utilisé par d’autres personnes, contribuez à la communauté ! Faites-le nous savoir et nous considérerons son éventuel ajout dans Django.
\n
\n\n","rootId":"middleware","toc":[{"title":"Activation des intergiciels","anchor":"activating-middleware","children":[]},{"title":"Points d’entrée et ordre des applications","anchor":"hooks-and-application-order","children":[]},{"title":"Écriture de son propre intergiciel","anchor":"writing-your-own-middleware","children":[{"title":"process_request()","anchor":"process-request","children":[]},{"title":"process_view()","anchor":"process-view","children":[]},{"title":"process_template_response()","anchor":"process-template-response","children":[]},{"title":"process_response()","anchor":"process-response","children":[{"title":"Gestion des réponses en flux","anchor":"dealing-with-streaming-responses","children":[]}]},{"title":"process_exception()","anchor":"process-exception","children":[]},{"title":"__init__()","anchor":"init","children":[{"title":"Signalement d’un intergiciel à exclure","anchor":"marking-middleware-as-unused","children":[]}]},{"title":"Lignes de conduite","anchor":"guidelines","children":[]}]}],"breadcrumbs":[{"docname":"topics/index","title":"Utilisation de Django","url":"/fr/1.9/topics/"},{"docname":"topics/http/index","title":"Gestion des requêtes HTTP","url":"/fr/1.9/topics/http/"}],"prev":{"docname":"topics/http/generic-views","title":"Vues génériques","url":"/fr/1.9/topics/http/generic-views/"},"next":{"docname":"topics/http/sessions","title":"Utilisation des sessions","url":"/fr/1.9/topics/http/sessions/"},"formats":{"html":"/fr/1.9/topics/http/middleware/","markdown":"/fr/1.9/topics/http/middleware.md","json":"/fr/1.9/topics/http/middleware.json"},"source":"https://github.com/django/django/blob/stable/1.9.x/docs/topics/http/middleware.txt","official":"https://docs.djangoproject.com/fr/1.9/topics/http/middleware/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","fr","ja","id","pt-br","es"]}
![\"middleware](\"../../../../../../_images/middleware.svg\")
\n\n