Normalized indentation and line lengths in docs/topics/auth/default.txt.

        {% endblock %}

    If you have customized authentication (see

    :doc:`Customizing Authentication </topics/auth/customizing>`) you can pass a custom authentication form

    to the login view via the ``authentication_form`` parameter. This form must

    accept a ``request`` keyword argument in its ``__init__`` method, and

    provide a ``get_user`` method which returns the authenticated user object

    (this method is only ever called after successful form validation).

    :doc:`Customizing Authentication </topics/auth/customizing>`) you can pass

    a custom authentication form to the login view via the

    ``authentication_form`` parameter. This form must accept a ``request``

    keyword argument in its ``__init__`` method, and provide a ``get_user()``

    method which returns the authenticated user object (this method is only

    ever called after successful form validation).

    .. _forms documentation: ../forms/

    .. _site framework docs: ../sites/

.. function:: logout(request, [next_page, template_name, redirect_field_name, current_app, extra_context])

    Logs a user out.

    :class:`~django.contrib.auth.forms.PasswordResetForm` and use the

    ``password_reset_form`` argument.

    Users flagged with an unusable password (see

    :meth:`~django.contrib.auth.models.User.set_unusable_password()` aren't

    allowed to request a password reset to prevent misuse when using an

    .. note::

        If the email address provided does not exist in the system, the user is inactive, or has an unusable password,

        the user will still be redirected to this view but no email will be sent.

        If the email address provided does not exist in the system, the user is

        inactive, or has an unusable password, the user will still be

        redirected to this view but no email will be sent.

    **Optional arguments:**

      URL to redirect to after log out. Overrides ``next`` if the given

      ``GET`` parameter is passed.

.. _built-in-auth-forms:

Built-in forms

    .. method:: confirm_login_allowed(user)

        By default, ``AuthenticationForm`` rejects users whose ``is_active`` flag

        is set to ``False``. You may override this behavior with a custom policy to

        determine which users can log in. Do this with a custom form that subclasses

        ``AuthenticationForm`` and overrides the ``confirm_login_allowed`` method.

        This method should raise a :exc:`~django.core.exceptions.ValidationError`

        if the given user may not log in.

        By default, ``AuthenticationForm`` rejects users whose ``is_active``

        flag is set to ``False``. You may override this behavior with a custom

        policy to determine which users can log in. Do this with a custom form

        that subclasses ``AuthenticationForm`` and overrides the

        ``confirm_login_allowed()`` method. This method should raise a

        :exc:`~django.core.exceptions.ValidationError` if the given user may

        not log in.

        For example, to allow all users to log in, regardless of "active" status::

        For example, to allow all users to log in regardless of "active"

        status::

            from django.contrib.auth.forms import AuthenticationForm

        :param subject_template_name: the template for the subject.

        :param email_template_name: the template for the email body.

        :param context: context passed to the ``subject_template``, ``email_template``,

            and ``html_email_template`` (if it is not ``None``).

        :param context: context passed to the ``subject_template``,

            ``email_template``, and ``html_email_template`` (if it is not

            ``None``).

        :param from_email: the sender's email.

        :param to_email: the email of the requester.

        :param html_email_template_name: the template for the HTML body;

.. currentmodule:: django.contrib.auth

Authentication data in templates

--------------------------------