diff options
Diffstat (limited to 'docs/topics/auth')
| -rw-r--r-- | docs/topics/auth/customizing.txt | 30 | ||||
| -rw-r--r-- | docs/topics/auth/default.txt | 15 | ||||
| -rw-r--r-- | docs/topics/auth/passwords.txt | 25 |
3 files changed, 34 insertions, 36 deletions
diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt index 4c9515fe53..453566d4cf 100644 --- a/docs/topics/auth/customizing.txt +++ b/docs/topics/auth/customizing.txt @@ -82,8 +82,8 @@ backends that follow. 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 simple - way to do that is simply to execute ``Session.objects.all().delete()``. + 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 --------------------------------- @@ -98,7 +98,7 @@ database ID or whatever, but has to be the primary key of your user object -- and returns a user object or ``None``. The ``authenticate`` method takes a ``request`` argument and credentials as -keyword arguments. Most of the time, it'll just look like this:: +keyword arguments. Most of the time, it'll look like this:: from django.contrib.auth.backends import BaseBackend @@ -197,7 +197,7 @@ exception in :meth:`~django.contrib.auth.models.User.has_perm()` or :meth:`~django.contrib.auth.models.User.has_module_perms()`, the authorization will immediately fail and Django won't check the backends that follow. -A backend could implement permissions for the magic admin fairly simply:: +A backend could implement permissions for the magic admin like this:: from django.contrib.auth.backends import BaseBackend @@ -729,7 +729,7 @@ Writing a manager for a custom user model You should also define a custom manager for your user model. If your user model defines ``username``, ``email``, ``is_staff``, ``is_active``, ``is_superuser``, ``last_login``, and ``date_joined`` fields the same as Django's default user, -you can just install Django's :class:`~django.contrib.auth.models.UserManager`; +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: @@ -793,10 +793,10 @@ Extending Django's default ``User`` ----------------------------------- If you're entirely happy with Django's :class:`~django.contrib.auth.models.User` -model and you just want to add some additional profile information, you could -simply subclass :class:`django.contrib.auth.models.AbstractUser` and add your -custom profile fields, although we'd recommend a separate model as described in -the "Model design considerations" note of :ref:`specifying-custom-user-model`. +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 the +"Model design considerations" note of :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>`. @@ -835,8 +835,8 @@ to work with a custom user model: * :class:`~django.contrib.auth.forms.UserCreationForm` * :class:`~django.contrib.auth.forms.UserChangeForm` -If your custom user model is a simple subclass of ``AbstractUser``, then you -can extend these forms in this manner:: +If your custom user model is a subclass of ``AbstractUser``, then you can +extend these forms in this manner:: from django.contrib.auth.forms import UserCreationForm from myapp.models import CustomUser @@ -1009,10 +1009,10 @@ A full example Here is an example of an admin-compliant custom user app. This user model uses an email address as the username, and has a required date of birth; it -provides no permission checking, beyond a simple ``admin`` flag on the user -account. This model would be compatible with all the built-in auth forms and -views, except for the user creation forms. This example illustrates how most of -the components work together, but is not intended to be copied directly into +provides no permission checking beyond an ``admin`` flag on the user account. +This model would be compatible with all the built-in auth forms and views, +except for the user creation forms. This example illustrates how most of the +components work together, but is not intended to be copied directly into projects for production use. This code would all live in a ``models.py`` file for a custom diff --git a/docs/topics/auth/default.txt b/docs/topics/auth/default.txt index 5f4c7a7a47..9f38fb70e4 100644 --- a/docs/topics/auth/default.txt +++ b/docs/topics/auth/default.txt @@ -150,7 +150,7 @@ Authenticating users Permissions and Authorization ============================= -Django comes with a simple permissions system. It provides a way to assign +Django comes with a built-in permissions system. It provides a way to assign permissions to specific users and groups of users. It's used by the Django admin site, but you're welcome to use it in your own @@ -473,7 +473,7 @@ Limiting access to logged-in users The raw way ~~~~~~~~~~~ -The simple, raw way to limit access to pages is to check +The raw way to limit access to pages is to check :attr:`request.user.is_authenticated <django.contrib.auth.models.User.is_authenticated>` and either redirect to a login page:: @@ -615,10 +615,9 @@ Limiting access to logged-in users that pass a test To limit access based on certain permissions or some other test, you'd do essentially the same thing as described in the previous section. -The simple way is to run your test on :attr:`request.user -<django.http.HttpRequest.user>` in the view directly. For example, this view -checks to make sure the user has an email in the desired domain and if not, -redirects to the login page:: +You can run your test on :attr:`request.user <django.http.HttpRequest.user>` in +the view directly. For example, this view checks to make sure the user has an +email in the desired domain and if not, redirects to the login page:: from django.shortcuts import redirect @@ -1015,8 +1014,8 @@ implementation details see :ref:`using-the-views`. * ``redirect_field_name``: The name of a ``GET`` field containing the URL to redirect to after login. Defaults to ``next``. - * ``authentication_form``: A callable (typically just a form class) to - use for authentication. Defaults to + * ``authentication_form``: A callable (typically a form class) to use for + authentication. Defaults to :class:`~django.contrib.auth.forms.AuthenticationForm`. * ``extra_context``: A dictionary of context data that will be added to the diff --git a/docs/topics/auth/passwords.txt b/docs/topics/auth/passwords.txt index 273ed33431..44e80911ba 100644 --- a/docs/topics/auth/passwords.txt +++ b/docs/topics/auth/passwords.txt @@ -423,8 +423,8 @@ Password validation Users often choose poor passwords. To help mitigate this problem, Django offers pluggable password validation. You can configure multiple password -validators at the same time. A few validators are included in Django, but it's -simple to write your own as well. +validators at the same time. A few validators are included in Django, but you +can write your own as well. Each password validator must provide a help text to explain the requirements to the user, validate a given password and return an error message if it does not @@ -434,7 +434,7 @@ Validators can also have optional settings to fine tune their behavior. Validation is controlled by the :setting:`AUTH_PASSWORD_VALIDATORS` setting. The default for the setting is an empty list, which means no validators are applied. In new projects created with the default :djadmin:`startproject` -template, a simple set of validators is enabled. +template, a set of validators is enabled by default. By default, validators are used in the forms to reset or change passwords and in the :djadmin:`createsuperuser` and :djadmin:`changepassword` management @@ -479,10 +479,9 @@ This example enables all four included validators: * ``UserAttributeSimilarityValidator``, which checks the similarity between the password and a set of attributes of the user. -* ``MinimumLengthValidator``, which simply checks whether the password meets a - minimum length. This validator is configured with a custom option: it now - requires the minimum length to be nine characters, instead of the default - eight. +* ``MinimumLengthValidator``, which checks whether the password meets a minimum + length. This validator is configured with a custom option: it now requires + the minimum length to be nine characters, instead of the default eight. * ``CommonPasswordValidator``, which checks whether the password occurs in a list of common passwords. By default, it compares to an included list of 20,000 common passwords. @@ -490,8 +489,8 @@ This example enables all four included validators: entirely numeric. For ``UserAttributeSimilarityValidator`` and ``CommonPasswordValidator``, -we're simply using the default settings in this example. -``NumericPasswordValidator`` has no settings. +we're using the default settings in this example. ``NumericPasswordValidator`` +has no settings. The help texts and any errors from password validators are always returned in the order they are listed in :setting:`AUTH_PASSWORD_VALIDATORS`. @@ -601,15 +600,15 @@ Writing your own validator -------------------------- If Django's built-in validators are not sufficient, you can write your own -password validators. Validators are fairly simple classes. They must implement -two methods: +password validators. Validators have a fairly small interface. They must +implement two methods: * ``validate(self, password, user=None)``: validate a password. Return ``None`` if the password is valid, or raise a :exc:`~django.core.exceptions.ValidationError` with an error message if the password is not valid. You must be able to deal with ``user`` being - ``None`` - if that means your validator can't run, simply return ``None`` - for no error. + ``None`` - if that means your validator can't run, return ``None`` for no + error. * ``get_help_text()``: provide a help text to explain the requirements to the user. |