Middleware is a framework of hooks into Django’s request/response processing.\nIt’s a light, low-level «plugin» system for globally altering Django’s input\nor output.
\nEach middleware component is responsible for doing some specific function. For\nexample, Django includes a middleware component,\nAuthenticationMiddleware, that\nassociates users with requests using sessions.
This document explains how middleware works, how you activate middleware, and\nhow to write your own middleware. Django ships with some built-in middleware\nyou can use right out of the box. They’re documented in the built-in\nmiddleware reference.
\nA middleware factory is a callable that takes a get_response callable and\nreturns a middleware. A middleware is a callable that takes a request and\nreturns a response, just like a view.
A middleware can be written as a function that looks like this:
\ndef simple_middleware(get_response):\n # One-time configuration and initialization.\n\n def middleware(request):\n # Code to be executed for each request before\n # the view (and later middleware) are called.\n\n response = get_response(request)\n\n # Code to be executed for each request/response after\n # the view is called.\n\n return response\n\n return middleware\nOr it can be written as a class whose instances are callable, like this:
\nclass SimpleMiddleware:\n def __init__(self, get_response):\n self.get_response = get_response\n # One-time configuration and initialization.\n\n def __call__(self, request):\n # Code to be executed for each request before\n # the view (and later middleware) are called.\n\n response = self.get_response(request)\n\n # Code to be executed for each request/response after\n # the view is called.\n\n return response\nThe get_response callable provided by Django might be the actual view (if\nthis is the last listed middleware) or it might be the next middleware in the\nchain. The current middleware doesn’t need to know or care what exactly it is,\njust that it represents whatever comes next.
The above is a slight simplification – the get_response callable for the\nlast middleware in the chain won’t be the actual view but rather a wrapper\nmethod from the handler which takes care of applying view middleware, calling the view with appropriate URL arguments, and\napplying template-response and\nexception middleware.
Middleware can either support only synchronous Python (the default), only\nasynchronous Python, or both. See Soporte asíncrono for details of how to\nadvertise what you support, and know what kind of request you are getting.
\nMiddleware can live anywhere on your Python path.
\n__init__(get_response)Link to this heading#Middleware factories must accept a get_response argument. You can also\ninitialize some global state for the middleware. Keep in mind a couple of\ncaveats:
Django initializes your middleware with only the get_response argument,\nso you can’t define __init__() as requiring any other arguments.
Unlike the __call__() method which is called once per request,\n__init__() is called only once, when the web server starts.
It’s sometimes useful to determine at startup time whether a piece of\nmiddleware should be used. In these cases, your middleware’s __init__()\nmethod may raise MiddlewareNotUsed. Django will\nthen remove that middleware from the middleware process and log a debug message\nto the django.request logger when DEBUG is True.
To activate a middleware component, add it to the MIDDLEWARE list in\nyour Django settings.
In MIDDLEWARE, each middleware component is represented by a string:\nthe full Python path to the middleware factory’s class or function name. For\nexample, here’s the default value created by django-admin\nstartproject:
MIDDLEWARE = [\n "django.middleware.security.SecurityMiddleware",\n "django.contrib.sessions.middleware.SessionMiddleware",\n "django.middleware.common.CommonMiddleware",\n "django.middleware.csrf.CsrfViewMiddleware",\n "django.contrib.auth.middleware.AuthenticationMiddleware",\n "django.contrib.messages.middleware.MessageMiddleware",\n "django.middleware.clickjacking.XFrameOptionsMiddleware",\n]\nA Django installation doesn’t require any middleware — MIDDLEWARE\ncan be empty, if you’d like — but it’s strongly suggested that you at least use\nCommonMiddleware.
The order in MIDDLEWARE matters because a middleware can depend on\nother middleware. For instance,\nAuthenticationMiddleware stores the\nauthenticated user in the session; therefore, it must run after\nSessionMiddleware. See\nMiddleware ordering for some common hints about ordering of Django\nmiddleware classes.
During the request phase, before calling the view, Django applies middleware in\nthe order it’s defined in MIDDLEWARE, top-down.
You can think of it like an onion: each middleware class is a «layer» that\nwraps the view, which is in the core of the onion. If the request passes\nthrough all the layers of the onion (each one calls get_response to pass\nthe request in to the next layer), all the way to the view at the core, the\nresponse will then pass through every layer (in reverse order) on the way back\nout.
If one of the layers decides to short-circuit and return a response without\never calling its get_response, none of the layers of the onion inside that\nlayer (including the view) will see the request or the response. The response\nwill only return through the same layers that the request passed in through.
Besides the basic request/response middleware pattern described earlier, you\ncan add three other special methods to class-based middleware:
\nprocess_view()Link to this heading#request is an HttpRequest object. view_func is\nthe Python function that Django is about to use. (It’s the actual function\nobject, not the name of the function as a string.) view_args is a list of\npositional arguments that will be passed to the view, and view_kwargs is a\ndictionary of keyword arguments that will be passed to the view. Neither\nview_args nor view_kwargs include the first view argument\n(request).
process_view() is called just before Django calls the view.
It should return either None or an HttpResponse\nobject. If it returns None, Django will continue processing this request,\nexecuting any other process_view() middleware and, then, the appropriate\nview. If it returns an HttpResponse object, Django won’t\nbother calling the appropriate view; it’ll apply response middleware to that\nHttpResponse and return the result.
process_exception()Link to this heading#request is an HttpRequest object. exception is an\nException object raised by the view function.
Django calls process_exception() when a view raises an exception.\nprocess_exception() should return either None or an\nHttpResponse object. If it returns an\nHttpResponse object, the template response and response\nmiddleware will be applied and the resulting response returned to the\nbrowser. Otherwise, default exception handling kicks in.
Again, middleware are run in reverse order during the response phase, which\nincludes process_exception. If an exception middleware returns a response,\nthe process_exception methods of the middleware classes above that\nmiddleware won’t be called at all.
process_template_response()Link to this heading#request is an HttpRequest object. response is\nthe TemplateResponse object (or equivalent)\nreturned by a Django view or by a middleware.
process_template_response() is called just after the view has finished\nexecuting, if the response instance has a render() method, indicating that\nit is a TemplateResponse or equivalent.
It must return a response object that implements a render method. It could\nalter the given response by changing response.template_name and\nresponse.context_data, or it could create and return a brand-new\nTemplateResponse or equivalent.
You don’t need to explicitly render responses – responses will be\nautomatically rendered once all template response middleware has been\ncalled.
\nMiddleware are run in reverse order during the response phase, which\nincludes process_template_response().
Unlike HttpResponse,\nStreamingHttpResponse does not have a content\nattribute. As a result, middleware can no longer assume that all responses\nwill have a content attribute. If they need access to the content, they\nmust test for streaming responses and adjust their behavior accordingly:
if response.streaming:\n response.streaming_content = wrap_streaming_content(response.streaming_content)\nelse:\n response.content = alter_content(response.content)\nStreamingHttpResponse allows both synchronous and\nasynchronous iterators. The wrapping function must match. Check\nStreamingHttpResponse.is_async if your middleware needs to\nsupport both types of iterator.
Django automatically converts exceptions raised by the view or by middleware\ninto an appropriate HTTP response with an error status code. Certain\nexceptions are converted to 4xx status codes, while an unknown\nexception is converted to a 500 status code.
\nThis conversion takes place before and after each middleware (you can think of\nit as the thin film in between each layer of the onion), so that every\nmiddleware can always rely on getting some kind of HTTP response back from\ncalling its get_response callable. Middleware don’t need to worry about\nwrapping their call to get_response in a try/except and handling an\nexception that might have been raised by a later middleware or the view. Even\nif the very next middleware in the chain raises an\nHttp404 exception, for example, your middleware won’t see\nthat exception; instead it will get an HttpResponse\nobject with a status_code of 404.
You can set DEBUG_PROPAGATE_EXCEPTIONS to True to skip this\nconversion and propagate exceptions upward.
Middleware can support any combination of synchronous and asynchronous\nrequests. Django will adapt requests to fit the middleware’s requirements if it\ncannot support both, but at a performance penalty.
\nBy default, Django assumes that your middleware is capable of handling only\nsynchronous requests. To change these assumptions, set the following attributes\non your middleware factory function or class:
\nsync_capable is a boolean indicating if the middleware can handle\nsynchronous requests. Defaults to True.
async_capable is a boolean indicating if the middleware can handle\nasynchronous requests. Defaults to False.
If your middleware has both sync_capable = True and\nasync_capable = True, then Django will pass it the request without\nconverting it. In this case, you can work out if your middleware will receive\nasync requests by checking if the get_response object you are passed is a\ncoroutine function, using inspect.iscoroutinefunction.
The django.utils.decorators module contains\nsync_only_middleware(),\nasync_only_middleware(), and\nsync_and_async_middleware() decorators that\nallow you to apply these flags to middleware factory functions.
The returned callable must match the sync or async nature of the\nget_response method. If you have an asynchronous get_response, you must\nreturn a coroutine function (async def).
process_view, process_template_response and process_exception\nmethods, if they are provided, should also be adapted to match the sync/async\nmode. However, Django will individually adapt them as required if you do not,\nat an additional performance penalty.
Here’s an example of how to create a middleware function that supports both:
\nfrom inspect import iscoroutinefunction\nfrom django.utils.decorators import sync_and_async_middleware\n\n\n@sync_and_async_middleware\ndef simple_middleware(get_response):\n # One-time configuration and initialization goes here.\n if iscoroutinefunction(get_response):\n\n async def middleware(request):\n # Do something here!\n response = await get_response(request)\n return response\n\n else:\n\n def middleware(request):\n # Do something here!\n response = get_response(request)\n return response\n\n return middleware\nWhen using an asynchronous class-based middleware, you must ensure that\ninstances are correctly marked as coroutine functions:
\nfrom inspect import iscoroutinefunction, markcoroutinefunction\n\n\nclass AsyncMiddleware:\n async_capable = True\n sync_capable = False\n\n def __init__(self, get_response):\n self.get_response = get_response\n if iscoroutinefunction(self.get_response):\n markcoroutinefunction(self)\n\n async def __call__(self, request):\n response = await self.get_response(request)\n # Some logic ...\n return response\nDjango provides django.utils.deprecation.MiddlewareMixin to ease creating\nmiddleware classes that are compatible with both MIDDLEWARE and the\nold MIDDLEWARE_CLASSES, and support synchronous and asynchronous requests.\nAll middleware classes included with Django are compatible with both settings.
The mixin provides an __init__() method that requires a get_response\nargument and stores it in self.get_response.
The __call__() method:
Calls self.process_request(request) (if defined).
Calls self.get_response(request) to get the response from later\nmiddleware and the view.
Calls self.process_response(request, response) (if defined).
Returns the response.
If used with MIDDLEWARE_CLASSES, the __call__() method will\nnever be used; Django calls process_request() and process_response()\ndirectly.
In most cases, inheriting from this mixin will be sufficient to make an\nold-style middleware compatible with the new system with sufficient\nbackwards-compatibility. The new short-circuiting semantics will be harmless or\neven beneficial to the existing middleware. In a few cases, a middleware class\nmay need some changes to adjust to the new semantics.
\nThese are the behavioral differences between using MIDDLEWARE and\nMIDDLEWARE_CLASSES:
Under MIDDLEWARE_CLASSES, every middleware will always have its\nprocess_response method called, even if an earlier middleware\nshort-circuited by returning a response from its process_request\nmethod. Under MIDDLEWARE, middleware behaves more like an onion:\nthe layers that a response goes through on the way out are the same layers\nthat saw the request on the way in. If a middleware short-circuits, only\nthat middleware and the ones before it in MIDDLEWARE will see the\nresponse.
Under MIDDLEWARE_CLASSES, process_exception is applied to\nexceptions raised from a middleware process_request method. Under\nMIDDLEWARE, process_exception applies only to exceptions\nraised from the view (or from the render method of a\nTemplateResponse). Exceptions raised from\na middleware are converted to the appropriate HTTP response and then passed\nto the next middleware.
Under MIDDLEWARE_CLASSES, if a process_response method raises\nan exception, the process_response methods of all earlier middleware are\nskipped and a 500 Internal Server Error HTTP response is always\nreturned (even if the exception raised was e.g. an\nHttp404). Under MIDDLEWARE, an exception\nraised from a middleware will immediately be converted to the appropriate\nHTTP response, and then the next middleware in line will see that\nresponse. Middleware are never skipped due to a middleware raising an\nexception.