mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 06:06:09 +00:00
Code Issues 32 Releases Wiki Activity

Refs #26601 -- Removed support for old-style middleware using settings.MIDDLEWARE_CLASSES.

Browse Source
This commit is contained in:
Tim Graham
2016-12-31 13:24:00 -05:00
parent 631f4ab061
commit d334f46b7a
29 changed files with 80 additions and 1367 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/ref/checks.txt
View File

@@ -323,19 +323,19 @@ The following checks are run if you use the :option:`check --deploy` option:
* **security.W001**: You do not have
:class:`django.middleware.security.SecurityMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES` so the :setting:`SECURE_HSTS_SECONDS`,
:setting:`MIDDLEWARE` so the :setting:`SECURE_HSTS_SECONDS`,
:setting:`SECURE_CONTENT_TYPE_NOSNIFF`, :setting:`SECURE_BROWSER_XSS_FILTER`,
and :setting:`SECURE_SSL_REDIRECT` settings will have no effect.
* **security.W002**: You do not have
:class:`django.middleware.clickjacking.XFrameOptionsMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, so your pages will not be served with an
:setting:`MIDDLEWARE`, so your pages will not be served with an
``'x-frame-options'`` header. Unless there is a good reason for your
site to be served in a frame, you should consider enabling this
header to help prevent clickjacking attacks.
* **security.W003**: You don't appear to be using Django's built-in cross-site
request forgery protection via the middleware
(:class:`django.middleware.csrf.CsrfViewMiddleware` is not in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`). Enabling the middleware is the safest
:setting:`MIDDLEWARE`). Enabling the middleware is the safest
approach to ensure you don't leave any holes.
* **security.W004**: You have not set a value for the
:setting:`SECURE_HSTS_SECONDS` setting. If your entire site is served only
@@ -372,10 +372,9 @@ The following checks are run if you use the :option:`check --deploy` option:
sessions.
* **security.W011**: You have
:class:`django.contrib.sessions.middleware.SessionMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but you have not set
:setting:`SESSION_COOKIE_SECURE` to ``True``. Using a secure-only session
cookie makes it more difficult for network traffic sniffers to hijack user
sessions.
:setting:`MIDDLEWARE`, but you have not set :setting:`SESSION_COOKIE_SECURE`
to ``True``. Using a secure-only session cookie makes it more difficult for
network traffic sniffers to hijack user sessions.
* **security.W012**: :setting:`SESSION_COOKIE_SECURE` is not set to ``True``.
Using a secure-only session cookie makes it more difficult for network traffic
sniffers to hijack user sessions.
@@ -386,10 +385,9 @@ The following checks are run if you use the :option:`check --deploy` option:
sessions.
* **security.W014**: You have
:class:`django.contrib.sessions.middleware.SessionMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but you have not set
:setting:`SESSION_COOKIE_HTTPONLY` to ``True``. Using an ``HttpOnly`` session
cookie makes it more difficult for cross-site scripting attacks to hijack user
sessions.
:setting:`MIDDLEWARE`, but you have not set :setting:`SESSION_COOKIE_HTTPONLY`
to ``True``. Using an ``HttpOnly`` session cookie makes it more difficult for
cross-site scripting attacks to hijack user sessions.
* **security.W015**: :setting:`SESSION_COOKIE_HTTPONLY` is not set to ``True``.
Using an ``HttpOnly`` session cookie makes it more difficult for cross-site
scripting attacks to hijack user sessions.
@@ -405,7 +403,7 @@ The following checks are run if you use the :option:`check --deploy` option:
deployment.
* **security.W019**: You have
:class:`django.middleware.clickjacking.XFrameOptionsMiddleware` in your
:setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but :setting:`X_FRAME_OPTIONS` is not set to
:setting:`MIDDLEWARE`, but :setting:`X_FRAME_OPTIONS` is not set to
``'DENY'``. The default is ``'SAMEORIGIN'``, but unless there is a good reason
for your site to serve other parts of itself in a frame, you should change
it to ``'DENY'``.

31
docs/ref/settings.txt
View File

@@ -9,9 +9,9 @@ Settings
.. warning::
Be careful when you override settings, especially when the default value
is a non-empty list or dictionary, such as :setting:`MIDDLEWARE_CLASSES`
and :setting:`STATICFILES_FINDERS`. Make sure you keep the components
required by the features of Django you wish to use.
is a non-empty list or dictionary, such as :setting:`STATICFILES_FINDERS`.
Make sure you keep the components required by the features of Django you
wish to use.
Core Settings
=============
@@ -1900,30 +1900,6 @@ Default:: ``None``
A list of middleware to use. See :doc:`/topics/http/middleware`.
.. setting:: MIDDLEWARE_CLASSES
``MIDDLEWARE_CLASSES``
----------------------
.. deprecated:: 1.10
Old-style middleware that uses ``settings.MIDDLEWARE_CLASSES`` are
deprecated. :ref:`Adapt old, custom middleware <upgrading-middleware>` and
use the :setting:`MIDDLEWARE` setting.
Default::
[
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
]
A list of middleware classes to use. This was the default setting used in
Django 1.9 and earlier. Django 1.10 introduced a new style of middleware. If
you have an older project using this setting you should :ref:`update any
middleware you've written yourself <upgrading-middleware>` to the new style
and then use the :setting:`MIDDLEWARE` setting.
.. setting:: MIGRATION_MODULES
``MIGRATION_MODULES``
@@ -3411,7 +3387,6 @@ HTTP
* :setting:`FORCE_SCRIPT_NAME`
* :setting:`INTERNAL_IPS`
* :setting:`MIDDLEWARE`
* :setting:`MIDDLEWARE_CLASSES`
* Security
* :setting:`SECURE_BROWSER_XSS_FILTER`