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

Refs #36485 -- Removed unnecessary parentheses in :meth: and :func: roles in docs.

Browse Source
This commit is contained in:
David Smith
2025-05-27 17:37:22 +01:00
committed by nessita
parent ef2f16bc48
commit 6f8e23d1c1
95 changed files with 445 additions and 445 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/topics/auth/customizing.txt
View File

@@ -46,7 +46,7 @@ Specifying authentication backends
Behind the scenes, Django maintains a list of "authentication backends" that it
checks for authentication. When somebody calls
:func:`django.contrib.auth.authenticate()` -- as described in :ref:`How to log
:func:`django.contrib.auth.authenticate` -- as described in :ref:`How to log
a user in <how-to-log-a-user-in>` -- Django tries authenticating across
all of its authentication backends. If the first authentication method fails,
Django tries the second one, and so on, until all backends have been attempted.
@@ -187,12 +187,12 @@ Handling authorization in custom backends
Custom auth backends can provide their own permissions.
The user model and its manager will delegate permission lookup functions
(:meth:`~django.contrib.auth.models.User.get_user_permissions()`,
:meth:`~django.contrib.auth.models.User.get_group_permissions()`,
:meth:`~django.contrib.auth.models.User.get_all_permissions()`,
:meth:`~django.contrib.auth.models.User.has_perm()`,
:meth:`~django.contrib.auth.models.User.has_module_perms()`, and
:meth:`~django.contrib.auth.models.UserManager.with_perm()`) to any
(:meth:`~django.contrib.auth.models.User.get_user_permissions`,
:meth:`~django.contrib.auth.models.User.get_group_permissions`,
:meth:`~django.contrib.auth.models.User.get_all_permissions`,
:meth:`~django.contrib.auth.models.User.has_perm`,
:meth:`~django.contrib.auth.models.User.has_module_perms`, and
:meth:`~django.contrib.auth.models.UserManager.with_perm`) to any
authentication backend that implements these functions.
The permissions given to the user will be the superset of all permissions
@@ -200,8 +200,8 @@ returned by all backends. That is, Django grants a permission to a user that
any one backend grants.
If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
exception in :meth:`~django.contrib.auth.models.User.has_perm()` or
:meth:`~django.contrib.auth.models.User.has_module_perms()`, the authorization
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 like this::
@@ -694,7 +694,7 @@ The following attributes and methods are available on any subclass of
When the raw_password is ``None``, the password will be set to an
unusable password, as if
:meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password()`
:meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password`
were used.
.. method:: models.AbstractBaseUser.check_password(raw_password)
@@ -710,7 +710,7 @@ 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
: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.
@@ -720,7 +720,7 @@ 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
:meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password` has
been called for this user.
.. method:: models.AbstractBaseUser.get_session_auth_hash()

46
docs/topics/auth/default.txt
View File

@@ -97,7 +97,7 @@ do not supply a user, the command will attempt to change the password
whose username matches the current system user.
You can also change a password programmatically, using
:meth:`~django.contrib.auth.models.User.set_password()`:
:meth:`~django.contrib.auth.models.User.set_password`:
.. code-block:: pycon
@@ -124,7 +124,7 @@ Authenticating users
*Asynchronous version*: ``aauthenticate()``
Use :func:`~django.contrib.auth.authenticate()` to verify a set of
Use :func:`~django.contrib.auth.authenticate` to verify a set of
credentials. It takes credentials as keyword arguments, ``username`` and
``password`` for the default case, checks them against each
:ref:`authentication backend <authentication-backends>`, and returns a
@@ -410,18 +410,18 @@ If you have an authenticated user you want to attach to the current session
*Asynchronous version*: ``alogin()``
To log a user in, from a view, use :func:`~django.contrib.auth.login()`. It
To log a user in, from a view, use :func:`~django.contrib.auth.login`. It
takes an :class:`~django.http.HttpRequest` object and a
:class:`~django.contrib.auth.models.User` object.
:func:`~django.contrib.auth.login()` saves the user's ID in the session,
:func:`~django.contrib.auth.login` saves the user's ID in the session,
using Django's session framework.
Note that any data set during the anonymous session is retained in the
session after a user logs in.
This example shows how you might use both
:func:`~django.contrib.auth.authenticate()` and
:func:`~django.contrib.auth.login()`::
:func:`~django.contrib.auth.authenticate` and
:func:`~django.contrib.auth.login`::
from django.contrib.auth import authenticate, login
@@ -449,9 +449,9 @@ is selected as follows:
#. Use the value of the optional ``backend`` argument, if provided.
#. Use the value of the ``user.backend`` attribute, if present. This allows
pairing :func:`~django.contrib.auth.authenticate()` and
:func:`~django.contrib.auth.login()`:
:func:`~django.contrib.auth.authenticate()`
pairing :func:`~django.contrib.auth.authenticate` and
:func:`~django.contrib.auth.login`:
:func:`~django.contrib.auth.authenticate`
sets the ``user.backend`` attribute on the user object it returns.
#. Use the ``backend`` in :setting:`AUTHENTICATION_BACKENDS`, if there is only
one.
@@ -470,8 +470,8 @@ How to log a user out
*Asynchronous version*: ``alogout()``
To log out a user who has been logged in via
:func:`django.contrib.auth.login()`, use
:func:`django.contrib.auth.logout()` within your view. It takes an
:func:`django.contrib.auth.login`, use
:func:`django.contrib.auth.logout` within your view. It takes an
:class:`~django.http.HttpRequest` object and has no return value.
Example::
@@ -482,16 +482,16 @@ How to log a user out
logout(request)
# Redirect to a success page.
Note that :func:`~django.contrib.auth.logout()` doesn't throw any errors if
Note that :func:`~django.contrib.auth.logout` doesn't throw any errors if
the user wasn't logged in.
When you call :func:`~django.contrib.auth.logout()`, the session data for
When you call :func:`~django.contrib.auth.logout`, the session data for
the current request is completely cleaned out. All existing data is
removed. This is to prevent another person from using the same web browser
to log in and have access to the previous user's session data. If you want
to put anything into the session that will be available to the user
immediately after logging out, do that *after* calling
:func:`django.contrib.auth.logout()`.
:func:`django.contrib.auth.logout`.
Limiting access to logged-in users
----------------------------------
@@ -769,7 +769,7 @@ The ``permission_required`` decorator
It's a relatively common task to check whether a user has a particular
permission. For that reason, Django provides a shortcut for that case: the
:func:`~django.contrib.auth.decorators.permission_required()` decorator::
:func:`~django.contrib.auth.decorators.permission_required` decorator::
from django.contrib.auth.decorators import permission_required
@@ -785,7 +785,7 @@ The ``permission_required`` decorator
The decorator may also take an iterable of permissions, in which case the
user must have all of the permissions in order to access the view.
Note that :func:`~django.contrib.auth.decorators.permission_required()`
Note that :func:`~django.contrib.auth.decorators.permission_required`
also takes an optional ``login_url`` parameter::
from django.contrib.auth.decorators import permission_required
@@ -856,8 +856,8 @@ To apply permission checks to :doc:`class-based views
Returns a boolean denoting whether the current user has permission to
execute the decorated view. By default, this returns the result of
calling :meth:`~django.contrib.auth.models.User.has_perms()` with the
list of permissions returned by :meth:`get_permission_required()`.
calling :meth:`~django.contrib.auth.models.User.has_perms` with the
list of permissions returned by :meth:`get_permission_required`.
Redirecting unauthorized requests in class-based views
------------------------------------------------------
@@ -930,7 +930,7 @@ Session invalidation on password change
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()`
: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. Django verifies that the hash in the session for
@@ -972,7 +972,7 @@ function.
.. note::
Since
:meth:`~django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash()`
:meth:`~django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash`
is based on :setting:`SECRET_KEY`, secret key values must be
rotated to avoid invalidating existing sessions when updating your site to
use a new secret. See :setting:`SECRET_KEY_FALLBACKS` for details.
@@ -1635,10 +1635,10 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`:
``password2`` are non empty and match, validates the password using
:func:`~django.contrib.auth.password_validation.validate_password`, and
sets the user's password using
:meth:`~django.contrib.auth.models.User.set_password()`.
:meth:`~django.contrib.auth.models.User.set_password`.
If ``usable_password`` is disabled, no password validation is done, and
password-based authentication is disabled for the user by calling
:meth:`~django.contrib.auth.models.User.set_unusable_password()`.
:meth:`~django.contrib.auth.models.User.set_unusable_password`.
.. class:: AuthenticationForm
@@ -1696,7 +1696,7 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`:
validates the password using
:func:`~django.contrib.auth.password_validation.validate_password`, and
sets the user's password using
:meth:`~django.contrib.auth.models.User.set_password()`.
:meth:`~django.contrib.auth.models.User.set_password`.
.. class:: PasswordChangeForm