mirror of
https://github.com/django/django.git
synced 2025-10-24 06:06:09 +00:00
Removed versionadded/changed annotations for 1.6.
This commit is contained in:
@@ -70,6 +70,10 @@ The order of :setting:`AUTHENTICATION_BACKENDS` matters, so if the same
|
||||
username and password is valid in multiple backends, Django will stop
|
||||
processing at the first positive match.
|
||||
|
||||
If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
|
||||
exception, authentication will immediately fail. Django won't check the
|
||||
backends that follow.
|
||||
|
||||
.. note::
|
||||
|
||||
Once a user has authenticated, Django stores which backend was used to
|
||||
@@ -81,12 +85,6 @@ processing at the first positive match.
|
||||
you need to force users to re-authenticate using different methods. A simple
|
||||
way to do that is simply to execute ``Session.objects.all().delete()``.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
|
||||
exception, authentication will immediately fail. Django won't check the
|
||||
backends that follow.
|
||||
|
||||
Writing an authentication backend
|
||||
---------------------------------
|
||||
|
||||
@@ -570,23 +568,12 @@ The following methods are available on any subclass of
|
||||
:meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password()`
|
||||
were used.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In Django 1.4 and 1.5, a blank string was unintentionally stored
|
||||
as an unusable password as well.
|
||||
|
||||
.. method:: models.AbstractBaseUser.check_password(raw_password)
|
||||
|
||||
Returns ``True`` if the given raw string is the correct password for
|
||||
the user. (This takes care of the password hashing in making the
|
||||
comparison.)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In Django 1.4 and 1.5, a blank string was unintentionally
|
||||
considered to be an unusable password, resulting in this method
|
||||
returning ``False`` for such a password.
|
||||
|
||||
.. method:: models.AbstractBaseUser.set_unusable_password()
|
||||
|
||||
Marks the user as having no password set. This isn't the same as
|
||||
@@ -909,10 +896,6 @@ models provided by ``auth`` app::
|
||||
"Run tests for a simple extension of the built-in User."
|
||||
self.assertSomething()
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In Django 1.5, it wasn't necessary to explicitly import the test User models.
|
||||
|
||||
A full example
|
||||
--------------
|
||||
|
||||
|
||||
@@ -851,11 +851,6 @@ patterns.
|
||||
error message since this would expose their account's existence but no
|
||||
mail will be sent either.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previously, error messages indicated whether a given email was
|
||||
registered.
|
||||
|
||||
**URL name:** ``password_reset``
|
||||
|
||||
**Optional arguments:**
|
||||
@@ -936,15 +931,9 @@ patterns.
|
||||
Someone asked for password reset for email {{ email }}. Follow the link below:
|
||||
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Reversing ``password_reset_confirm`` takes a ``uidb64`` argument instead
|
||||
of ``uidb36``.
|
||||
|
||||
The same template context is used for subject template. Subject must be
|
||||
single line plain text string.
|
||||
|
||||
|
||||
.. function:: password_reset_done(request[, template_name, current_app, extra_context])
|
||||
|
||||
The page shown after a user has been emailed a link to reset their
|
||||
@@ -976,11 +965,6 @@ patterns.
|
||||
|
||||
* ``uidb64``: The user's id encoded in base 64. Defaults to ``None``.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``uidb64`` parameter was previously base 36 encoded and named
|
||||
``uidb36``.
|
||||
|
||||
* ``token``: Token to check that the password is valid. Defaults to
|
||||
``None``.
|
||||
|
||||
|
||||
@@ -183,11 +183,8 @@ can switch to new (and better) storage algorithms as they get invented.
|
||||
However, Django can only upgrade passwords that use algorithms mentioned in
|
||||
:setting:`PASSWORD_HASHERS`, so as you upgrade to new systems you should make
|
||||
sure never to *remove* entries from this list. If you do, users using
|
||||
unmentioned algorithms won't be able to upgrade.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
Passwords will be upgraded when changing the PBKDF2 iteration count.
|
||||
unmentioned algorithms won't be able to upgrade. Passwords will be upgraded
|
||||
when changing the PBKDF2 iteration count.
|
||||
|
||||
.. _sha1: http://en.wikipedia.org/wiki/SHA1
|
||||
.. _pbkdf2: http://en.wikipedia.org/wiki/PBKDF2
|
||||
@@ -214,12 +211,6 @@ from the ``User`` model.
|
||||
database to check against, and returns ``True`` if they match, ``False``
|
||||
otherwise.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In Django 1.4 and 1.5, a blank string was unintentionally considered
|
||||
to be an unusable password, resulting in this method returning
|
||||
``False`` for such a password.
|
||||
|
||||
.. function:: make_password(password[, salt, hashers])
|
||||
|
||||
Creates a hashed password in the format used by this application. It takes
|
||||
|
||||
Reference in New Issue
Block a user