diff options
Diffstat (limited to 'docs/topics/auth/customizing.txt')
| -rw-r--r-- | docs/topics/auth/customizing.txt | 40 |
1 files changed, 21 insertions, 19 deletions
diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt index 5ef1ea5bbd..505beb5289 100644 --- a/docs/topics/auth/customizing.txt +++ b/docs/topics/auth/customizing.txt @@ -81,8 +81,8 @@ backends that follow. for the duration of that session whenever access to the currently authenticated user is needed. This effectively means that authentication sources are cached on a per-session basis, so if you change - :setting:`AUTHENTICATION_BACKENDS`, you'll need to clear out session data if - you need to force users to re-authenticate using different methods. A + :setting:`AUTHENTICATION_BACKENDS`, you'll need to clear out session data + if you need to force users to re-authenticate using different methods. A simple way to do that is to execute ``Session.objects.all().delete()``. Writing an authentication backend @@ -474,8 +474,8 @@ different user model. Instead of referring to :class:`~django.contrib.auth.models.User` directly, you should reference the user model using ``django.contrib.auth.get_user_model()``. This method will return the - currently active user model -- the custom user model if one is specified, or - :class:`~django.contrib.auth.models.User` otherwise. + currently active user model -- the custom user model if one is specified, + or :class:`~django.contrib.auth.models.User` otherwise. When you define a foreign key or many-to-many relations to the user model, you should specify the custom model using the :setting:`AUTH_USER_MODEL` @@ -491,8 +491,8 @@ different user model. on_delete=models.CASCADE, ) - When connecting to signals sent by the user model, you should specify - the custom model using the :setting:`AUTH_USER_MODEL` setting. For example:: + When connecting to signals sent by the user model, you should specify the + custom model using the :setting:`AUTH_USER_MODEL` setting. For example:: from django.conf import settings from django.db.models.signals import post_save @@ -682,9 +682,9 @@ The following attributes and methods are available on any subclass of .. attribute:: models.AbstractBaseUser.is_anonymous Read-only attribute which is always ``False``. This is a way of - differentiating :class:`~models.User` and :class:`~models.AnonymousUser` - objects. Generally, you should prefer using - :attr:`~models.User.is_authenticated` to this attribute. + differentiating :class:`~models.User` and + :class:`~models.AnonymousUser` objects. Generally, you should prefer + using :attr:`~models.User.is_authenticated` to this attribute. .. method:: models.AbstractBaseUser.set_password(raw_password) @@ -710,8 +710,8 @@ The following attributes and methods are available on any subclass of Marks the user as having no password set. This isn't the same as having a blank string for a password. - :meth:`~django.contrib.auth.models.AbstractBaseUser.check_password` for this user - will never return ``True``. Doesn't save the + :meth:`~django.contrib.auth.models.AbstractBaseUser.check_password` for + this user will never return ``True``. Doesn't save the :class:`~django.contrib.auth.models.AbstractBaseUser` object. You may need this if authentication for your application takes place @@ -720,8 +720,8 @@ The following attributes and methods are available on any subclass of .. method:: models.AbstractBaseUser.has_usable_password() Returns ``False`` if - :meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password` has - been called for this user. + :meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password` + has been called for this user. .. method:: models.AbstractBaseUser.get_session_auth_hash() @@ -751,8 +751,9 @@ defines ``username``, ``email``, ``is_staff``, ``is_active``, ``is_superuser``, ``last_login``, and ``date_joined`` fields the same as Django's default user, you can install Django's :class:`~django.contrib.auth.models.UserManager`; however, if your user model defines different fields, you'll need to define a -custom manager that extends :class:`~django.contrib.auth.models.BaseUserManager` -providing two additional methods: +custom manager that extends +:class:`~django.contrib.auth.models.BaseUserManager` providing two additional +methods: .. class:: models.CustomUserManager @@ -808,10 +809,11 @@ utility methods: Extending Django's default ``User`` ----------------------------------- -If you're entirely happy with Django's :class:`~django.contrib.auth.models.User` -model, but you want to add some additional profile information, you could -subclass :class:`django.contrib.auth.models.AbstractUser` and add your custom -profile fields, although we'd recommend a separate model as described in +If you're entirely happy with Django's +:class:`~django.contrib.auth.models.User` model, but you want to add some +additional profile information, you could subclass +:class:`django.contrib.auth.models.AbstractUser` and add your custom profile +fields, although we'd recommend a separate model as described in :ref:`specifying-custom-user-model`. ``AbstractUser`` provides the full implementation of the default :class:`~django.contrib.auth.models.User` as an :ref:`abstract model <abstract-base-classes>`. |