django1/docs/ref/middleware.txt

306 lines
9.8 KiB
Plaintext
Raw Normal View History

==========
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, among 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``.
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>`.
Site middleware
---------------
.. module:: django.contrib.sites.middleware
:synopsis: Site middleware.
.. class:: CurrentSiteMiddleware
.. versionadded:: 1.7
Adds the ``site`` attribute representing the current site to every incoming
``HttpRequest`` object. See the :ref:`sites documentation <site-middleware>`.
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>`.
.. class:: RemoteUserMiddleware
Middleware for utilizing Web server provided authentication. See
:doc:`/howto/auth-remote-user` for usage details.
.. class:: SessionAuthenticationMiddleware
.. versionadded:: 1.7
Allows a user's sessions to be invalidated when their password changes. See
:ref:`session-invalidation-on-password-change` for details. This middleware must
appear after :class:`django.contrib.auth.middleware.AuthenticationMiddleware`
in :setting:`MIDDLEWARE_CLASSES`.
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>`.
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/>`.
.. _middleware-ordering:
Middleware ordering
===================
Here are some hints about the ordering of various Django middleware classes:
#. :class:`~django.middleware.cache.UpdateCacheMiddleware`
Before those that modify the ``Vary`` header (``SessionMiddleware``,
``GZipMiddleware``, ``LocaleMiddleware``).
#. :class:`~django.middleware.gzip.GZipMiddleware`
Before any middleware that may change or use the response body.
After ``UpdateCacheMiddleware``: Modifies ``Vary`` header.
#. :class:`~django.middleware.http.ConditionalGetMiddleware`
Before ``CommonMiddleware``: uses its ``Etag`` header when
:setting:`USE_ETAGS` = ``True``.
#. :class:`~django.contrib.sessions.middleware.SessionMiddleware`
After ``UpdateCacheMiddleware``: Modifies ``Vary`` header.
#. :class:`~django.middleware.locale.LocaleMiddleware`
One of the topmost, after ``SessionMiddleware`` (uses session data) and
``CacheMiddleware`` (modifies ``Vary`` header).
#. :class:`~django.middleware.common.CommonMiddleware`
Before any middleware that may change the response (it calculates ``ETags``).
After ``GZipMiddleware`` so it won't calculate an ``ETag`` header on gzipped
contents.
Close to the top: it redirects when :setting:`APPEND_SLASH` or
:setting:`PREPEND_WWW` are set to ``True``.
#. :class:`~django.middleware.csrf.CsrfViewMiddleware`
Before any view middleware that assumes that CSRF attacks have been dealt
with.
#. :class:`~django.contrib.auth.middleware.AuthenticationMiddleware`
After ``SessionMiddleware``: uses session storage.
#. :class:`~django.contrib.messages.middleware.MessageMiddleware`
After ``SessionMiddleware``: can use session-based storage.
#. :class:`~django.middleware.cache.FetchFromCacheMiddleware`
After any middleware that modifies the ``Vary`` header: that header is used
to pick a value for the cache hash-key.
#. :class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware`
Should be near the bottom as it's a last-resort type of middleware.
#. :class:`~django.contrib.redirects.middleware.RedirectFallbackMiddleware`
Should be near the bottom as it's a last-resort type of middleware.