mirror of
				https://github.com/django/django.git
				synced 2025-10-28 16:16:12 +00:00 
			
		
		
		
	
		
			
				
	
	
		
			240 lines
		
	
	
		
			8.1 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			240 lines
		
	
	
		
			8.1 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| ==========
 | |
| Middleware
 | |
| ==========
 | |
| 
 | |
| .. module:: django.middleware
 | |
|    :synopsis: Django's built-in middleware classes.
 | |
| 
 | |
| This document explains all middleware components that come with Django. For
 | |
| information on how to use them and how to write your own middleware, see
 | |
| the :doc:`middleware usage guide </topics/http/middleware>`.
 | |
| 
 | |
| Available middleware
 | |
| ====================
 | |
| 
 | |
| Cache middleware
 | |
| ----------------
 | |
| 
 | |
| .. module:: django.middleware.cache
 | |
|    :synopsis: Middleware for the site-wide cache.
 | |
| 
 | |
| .. class:: UpdateCacheMiddleware
 | |
| 
 | |
| .. class:: FetchFromCacheMiddleware
 | |
| 
 | |
| Enable the site-wide cache. If these are enabled, each Django-powered page will
 | |
| be cached for as long as the :setting:`CACHE_MIDDLEWARE_SECONDS` setting
 | |
| defines. See the :doc:`cache documentation </topics/cache>`.
 | |
| 
 | |
| "Common" middleware
 | |
| -------------------
 | |
| 
 | |
| .. module:: django.middleware.common
 | |
|    :synopsis: Middleware adding "common" conveniences for perfectionists.
 | |
| 
 | |
| .. class:: CommonMiddleware
 | |
| 
 | |
| Adds a few conveniences for perfectionists:
 | |
| 
 | |
| * Forbids access to user agents in the :setting:`DISALLOWED_USER_AGENTS`
 | |
|   setting, which should be a list of compiled regular expression objects.
 | |
| 
 | |
| * Performs URL rewriting based on the :setting:`APPEND_SLASH` and
 | |
|   :setting:`PREPEND_WWW` settings.
 | |
| 
 | |
|   If :setting:`APPEND_SLASH` is ``True`` and the initial URL doesn't end
 | |
|   with a slash, and it is not found in the URLconf, then a new URL is
 | |
|   formed by appending a slash at the end. If this new URL is found in the
 | |
|   URLconf, then Django redirects the request to this new URL. Otherwise,
 | |
|   the initial URL is processed as usual.
 | |
| 
 | |
|   For example, ``foo.com/bar`` will be redirected to ``foo.com/bar/`` if
 | |
|   you don't have a valid URL pattern for ``foo.com/bar`` but *do* have a
 | |
|   valid pattern for ``foo.com/bar/``.
 | |
| 
 | |
|   If :setting:`PREPEND_WWW` is ``True``, URLs that lack a leading "www."
 | |
|   will be redirected to the same URL with a leading "www."
 | |
| 
 | |
|   Both of these options are meant to normalize URLs. The philosophy is that
 | |
|   each URL should exist in one, and only one, place. Technically a URL
 | |
|   ``foo.com/bar`` is distinct from ``foo.com/bar/`` -- a search-engine
 | |
|   indexer would treat them as separate URLs -- so it's best practice to
 | |
|   normalize URLs.
 | |
| 
 | |
| * Handles ETags based on the :setting:`USE_ETAGS` setting. If
 | |
|   :setting:`USE_ETAGS` is set to ``True``, Django will calculate an ETag
 | |
|   for each request by MD5-hashing the page content, and it'll take care of
 | |
|   sending ``Not Modified`` responses, if appropriate.
 | |
| 
 | |
| .. class:: BrokenLinkEmailsMiddleware
 | |
| 
 | |
| * Sends broken link notification emails to :setting:`MANAGERS` (see
 | |
|   :doc:`/howto/error-reporting`).
 | |
| 
 | |
| GZip middleware
 | |
| ---------------
 | |
| 
 | |
| .. module:: django.middleware.gzip
 | |
|    :synopsis: Middleware to serve GZipped content for performance.
 | |
| 
 | |
| .. class:: GZipMiddleware
 | |
| 
 | |
| .. warning::
 | |
| 
 | |
|     Security researchers recently revealed that when compression techniques
 | |
|     (including ``GZipMiddleware``) are used on a website, the site becomes
 | |
|     exposed to a number of possible attacks. These approaches can be used to
 | |
|     compromise, amongst other things, Django's CSRF protection. Before using
 | |
|     ``GZipMiddleware`` on your site, you should consider very carefully whether
 | |
|     you are subject to these attacks. If you're in *any* doubt about whether
 | |
|     you're affected, you should avoid using ``GZipMiddleware``. For more
 | |
|     details, see the `the BREACH paper (PDF)`_ and `breachattack.com`_.
 | |
| 
 | |
|     .. _the BREACH paper (PDF): http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf
 | |
|     .. _breachattack.com: http://breachattack.com
 | |
| 
 | |
| Compresses content for browsers that understand GZip compression (all modern
 | |
| browsers).
 | |
| 
 | |
| This middleware should be placed before any other middleware that need to
 | |
| read or write the response body so that compression happens afterward.
 | |
| 
 | |
| It will NOT compress content if any of the following are true:
 | |
| 
 | |
| * The content body is less than 200 bytes long.
 | |
| 
 | |
| * The response has already set the ``Content-Encoding`` header.
 | |
| 
 | |
| * The request (the browser) hasn't sent an ``Accept-Encoding`` header
 | |
|   containing ``gzip``.
 | |
| 
 | |
| * The request is from Internet Explorer and the ``Content-Type`` header
 | |
|   contains ``javascript`` or starts with anything other than ``text/``.
 | |
|   We do this to avoid a bug in early versions of IE that caused decompression
 | |
|   not to be performed on certain content types.
 | |
| 
 | |
| You can apply GZip compression to individual views using the
 | |
| :func:`~django.views.decorators.gzip.gzip_page()` decorator.
 | |
| 
 | |
| Conditional GET middleware
 | |
| --------------------------
 | |
| 
 | |
| .. module:: django.middleware.http
 | |
|    :synopsis: Middleware handling advanced HTTP features.
 | |
| 
 | |
| .. class:: ConditionalGetMiddleware
 | |
| 
 | |
| Handles conditional GET operations. If the response has a ``ETag`` or
 | |
| ``Last-Modified`` header, and the request has ``If-None-Match`` or
 | |
| ``If-Modified-Since``, the response is replaced by an
 | |
| :class:`~django.http.HttpResponseNotModified`.
 | |
| 
 | |
| Also sets the ``Date`` and ``Content-Length`` response-headers.
 | |
| 
 | |
| Reverse proxy middleware
 | |
| ------------------------
 | |
| 
 | |
| .. class:: SetRemoteAddrFromForwardedFor
 | |
| 
 | |
| This middleware was removed in Django 1.1. See :ref:`the release notes
 | |
| <removed-setremoteaddrfromforwardedfor-middleware>` for details.
 | |
| 
 | |
| Locale middleware
 | |
| -----------------
 | |
| 
 | |
| .. module:: django.middleware.locale
 | |
|    :synopsis: Middleware to enable language selection based on the request.
 | |
| 
 | |
| .. class:: LocaleMiddleware
 | |
| 
 | |
| Enables language selection based on data from the request. It customizes
 | |
| content for each user. See the :doc:`internationalization documentation
 | |
| </topics/i18n/translation>`.
 | |
| 
 | |
| .. attribute:: LocaleMiddleware.response_redirect_class
 | |
| 
 | |
| Defaults to :class:`~django.http.HttpResponseRedirect`. Subclass
 | |
| ``LocaleMiddleware`` and override the attribute to customize the redirects
 | |
| issued by the middleware.
 | |
| 
 | |
| Message middleware
 | |
| ------------------
 | |
| 
 | |
| .. module:: django.contrib.messages.middleware
 | |
|    :synopsis: Message middleware.
 | |
| 
 | |
| .. class:: MessageMiddleware
 | |
| 
 | |
| Enables cookie- and session-based message support. See the
 | |
| :doc:`messages documentation </ref/contrib/messages>`.
 | |
| 
 | |
| Session middleware
 | |
| ------------------
 | |
| 
 | |
| .. module:: django.contrib.sessions.middleware
 | |
|    :synopsis: Session middleware.
 | |
| 
 | |
| .. class:: SessionMiddleware
 | |
| 
 | |
| Enables session support. See the :doc:`session documentation
 | |
| </topics/http/sessions>`.
 | |
| 
 | |
| Authentication middleware
 | |
| -------------------------
 | |
| 
 | |
| .. module:: django.contrib.auth.middleware
 | |
|   :synopsis: Authentication middleware.
 | |
| 
 | |
| .. class:: AuthenticationMiddleware
 | |
| 
 | |
| Adds the ``user`` attribute, representing the currently-logged-in user, to
 | |
| every incoming ``HttpRequest`` object. See :ref:`Authentication in Web requests
 | |
| <auth-web-requests>`.
 | |
| 
 | |
| CSRF protection middleware
 | |
| --------------------------
 | |
| 
 | |
| .. module:: django.middleware.csrf
 | |
|    :synopsis: Middleware adding protection against Cross Site Request
 | |
|               Forgeries.
 | |
| 
 | |
| .. class:: CsrfViewMiddleware
 | |
| 
 | |
| Adds protection against Cross Site Request Forgeries by adding hidden form
 | |
| fields to POST forms and checking requests for the correct value. See the
 | |
| :doc:`Cross Site Request Forgery protection documentation </ref/contrib/csrf>`.
 | |
| 
 | |
| Transaction middleware
 | |
| ----------------------
 | |
| 
 | |
| .. module:: django.middleware.transaction
 | |
|    :synopsis: Middleware binding a database transaction to each Web request.
 | |
| 
 | |
| .. class:: TransactionMiddleware
 | |
| 
 | |
| .. versionchanged:: 1.6
 | |
| 
 | |
|     ``TransactionMiddleware`` is deprecated. The documentation of transactions
 | |
|     contains :ref:`upgrade instructions <transactions-upgrading-from-1.5>`.
 | |
| 
 | |
| Binds commit and rollback of the default database to the request/response
 | |
| phase. If a view function runs successfully, a commit is done. If it fails with
 | |
| an exception, a rollback is done.
 | |
| 
 | |
| The order of this middleware in the stack is important: middleware modules
 | |
| running outside of it run with commit-on-save - the default Django behavior.
 | |
| Middleware modules running inside it (coming later in the stack) will be under
 | |
| the same transaction control as the view functions.
 | |
| 
 | |
| See the :doc:`transaction management documentation </topics/db/transactions>`.
 | |
| 
 | |
| X-Frame-Options middleware
 | |
| --------------------------
 | |
| 
 | |
| .. module:: django.middleware.clickjacking
 | |
|    :synopsis: Clickjacking protection
 | |
| 
 | |
| .. class:: XFrameOptionsMiddleware
 | |
| 
 | |
| Simple :doc:`clickjacking protection via the X-Frame-Options header </ref/clickjacking/>`.
 |