|
@@ -108,9 +108,8 @@ Django also provides :ref:`views <built-in-auth-views>` and :ref:`forms
|
|
|
<built-in-auth-forms>` that may be used to allow users to change their own
|
|
|
passwords.
|
|
|
|
|
|
-Changing a user's password will log out all their sessions if the
|
|
|
-:class:`~django.contrib.auth.middleware.SessionAuthenticationMiddleware` is
|
|
|
-enabled. See :ref:`session-invalidation-on-password-change` for details.
|
|
|
+Changing a user's password will log out all their sessions. See
|
|
|
+:ref:`session-invalidation-on-password-change` for details.
|
|
|
|
|
|
Authenticating Users
|
|
|
--------------------
|
|
@@ -801,29 +800,23 @@ user to the login page or issue an HTTP 403 Forbidden response.
|
|
|
Session invalidation on password change
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
-.. warning::
|
|
|
+.. versionchanged:: 1.10
|
|
|
|
|
|
- This protection only applies if
|
|
|
- :class:`~django.contrib.auth.middleware.SessionAuthenticationMiddleware`
|
|
|
- is enabled in :setting:`MIDDLEWARE_CLASSES`. It's included if
|
|
|
- ``settings.py`` was generated by :djadmin:`startproject` on Django ≥ 1.7.
|
|
|
-
|
|
|
- Session verification will become mandatory in Django 1.10 regardless of
|
|
|
- whether or not ``SessionAuthenticationMiddleware`` is enabled. If you have
|
|
|
- a pre-1.7 project or one generated using a template that doesn't include
|
|
|
- ``SessionAuthenticationMiddleware``, consider enabling it before then after
|
|
|
- reading the upgrade considerations below.
|
|
|
+ Session verification is enabled and mandatory in Django 1.10 (there's no
|
|
|
+ way to disable it) regardless of whether or not
|
|
|
+ ``SessionAuthenticationMiddleware`` is enabled. In older
|
|
|
+ versions, this protection only applies if
|
|
|
+ ``django.contrib.auth.middleware.SessionAuthenticationMiddleware``
|
|
|
+ is enabled in :setting:`MIDDLEWARE_CLASSES`.
|
|
|
|
|
|
If your :setting:`AUTH_USER_MODEL` inherits from
|
|
|
:class:`~django.contrib.auth.models.AbstractBaseUser` or implements its own
|
|
|
:meth:`~django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash()`
|
|
|
method, authenticated sessions will include the hash returned by this function.
|
|
|
In the :class:`~django.contrib.auth.models.AbstractBaseUser` case, this is an
|
|
|
-HMAC of the password field. If the
|
|
|
-:class:`~django.contrib.auth.middleware.SessionAuthenticationMiddleware` is
|
|
|
-enabled, Django verifies that the hash sent along with each request matches
|
|
|
-the one that's computed server-side. This allows a user to log out all of their
|
|
|
-sessions by changing their password.
|
|
|
+HMAC of the password field. Django verifies that the hash sent along with each
|
|
|
+request matches the one that's computed server-side. This allows a user to log
|
|
|
+out all of their sessions by changing their password.
|
|
|
|
|
|
The default password change views included with Django,
|
|
|
:func:`django.contrib.auth.views.password_change` and the
|
|
@@ -849,15 +842,6 @@ and wish to have similar behavior, use this function:
|
|
|
else:
|
|
|
...
|
|
|
|
|
|
-If you are upgrading an existing site and wish to enable this middleware without
|
|
|
-requiring all your users to re-login afterward, you should first upgrade to
|
|
|
-Django 1.7 and run it for a while so that as sessions are naturally recreated
|
|
|
-as users login, they include the session hash as described above. Once you
|
|
|
-start running your site with
|
|
|
-:class:`~django.contrib.auth.middleware.SessionAuthenticationMiddleware`, any
|
|
|
-users who have not logged in and had their session updated with the verification
|
|
|
-hash will have their existing session invalidated and be required to login.
|
|
|
-
|
|
|
.. note::
|
|
|
|
|
|
Since
|