<commit_before>.. _topics-auth:

=============================
User authentication in Django
=============================

.. module:: django.contrib.auth
   :synopsis: Django's authentication framework.

Django comes with a user authentication system. It handles user accounts,
groups, permissions and cookie-based user sessions. This document explains how
things work.

Overview
========

The auth system consists of:

    * Users
    * Permissions: Binary (yes/no) flags designating whether a user may perform
      a certain task.
    * Groups: A generic way of applying labels and permissions to more than one
      user.
    * Messages: A simple way to queue messages for given users.

.. deprecated:: 1.2
   The Messages component of the auth system will be removed in Django 1.4.
 
Installation
============

Authentication support is bundled as a Django application in
``django.contrib.auth``. To install it, do the following:

    1. Put ``'django.contrib.auth'`` and ``'django.contrib.contenttypes'`` in
       your :setting:`INSTALLED_APPS` setting.
       (The :class:`~django.contrib.auth.models.Permission` model in
       :mod:`django.contrib.auth` depends on :mod:`django.contrib.contenttypes`.)
    2. Run the command ``manage.py syncdb``.

Note that the default :file:`settings.py` file created by
:djadmin:`django-admin.py startproject` includes ``'django.contrib.auth'`` and
``'django.contrib.contenttypes'`` in :setting:`INSTALLED_APPS` for convenience.
If your :setting:`INSTALLED_APPS` already contains these apps, feel free to run
:djadmin:`manage.py syncdb` again; you can run that command as many times as
you'd like, and each time it'll only install what's needed.

The :djadmin:`syncdb` command creates the necessary database tables, creates
permission objects for all installed apps that need 'em, and prompts you to
create a superuser account the first time you run it.

Once you've taken those steps, that's it.

Users
=====

.. class:: models.User

API reference
-------------

Fields
~~~~~~

.. class:: models.User

    :class:`~django.contrib.auth.models.User` objects have the following
    fields:

    .. attribute:: models.User.username

        Required. 30 characters or fewer. Alphanumeric characters only
        (letters, digits and underscores).

    .. attribute:: models.User.first_name

        Optional. 30 characters or fewer.

    .. attribute:: models.User.last_name

        Optional. 30 characters or fewer.

    .. attribute:: models.User.email

        Optional. E-mail address.

    .. attribute:: models.User.password

        Required. A hash of, and metadata about, the password. (Django doesn't
        store the raw password.) Raw passwords can be arbitrarily long and can
        contain any character. See the "Passwords" section below.

    .. attribute:: models.User.is_staff

        Boolean. Designates whether this user can access the admin site.

    .. attribute:: models.User.is_active

        Boolean. Designates whether this user account should be considered
        active. Set this flag to ``False`` instead of deleting accounts.

        This doesn't control whether or not the user can log in. Nothing in the
        authentication path checks the ``is_active`` flag, so if you want to
        reject a login based on ``is_active`` being ``False``, it is up to you
        to check that in your own login view. However, permission checking
        using the methods like :meth:`~models.User.has_perm` does check this
        flag and will always return ``False`` for inactive users.

    .. attribute:: models.User.is_superuser

        Boolean. Designates that this user has all permissions without
        explicitly assigning them.

    .. attribute:: models.User.last_login

        A datetime of the user's last login. Is set to the current date/time by
        default.

    .. attribute:: models.User.date_joined

        A datetime designating when the account was created. Is set to the
        current date/time by default when the account is created.

Methods
~~~~~~~

.. class:: models.User
<commit_msg>Fixed #12113 -- Clarified is_active documentation. Thanks, ejucovy and isagalaev<commit_after>.. _topics-auth:

=============================
User authentication in Django
=============================

.. module:: django.contrib.auth
   :synopsis: Django's authentication framework.

Django comes with a user authentication system. It handles user accounts,
groups, permissions and cookie-based user sessions. This document explains how
things work.

Overview
========

The auth system consists of:

    * Users
    * Permissions: Binary (yes/no) flags designating whether a user may perform
      a certain task.
    * Groups: A generic way of applying labels and permissions to more than one
      user.
    * Messages: A simple way to queue messages for given users.

.. deprecated:: 1.2
   The Messages component of the auth system will be removed in Django 1.4.
 
Installation
============

Authentication support is bundled as a Django application in
``django.contrib.auth``. To install it, do the following:

    1. Put ``'django.contrib.auth'`` and ``'django.contrib.contenttypes'`` in
       your :setting:`INSTALLED_APPS` setting.
       (The :class:`~django.contrib.auth.models.Permission` model in
       :mod:`django.contrib.auth` depends on :mod:`django.contrib.contenttypes`.)
    2. Run the command ``manage.py syncdb``.

Note that the default :file:`settings.py` file created by
:djadmin:`django-admin.py startproject` includes ``'django.contrib.auth'`` and
``'django.contrib.contenttypes'`` in :setting:`INSTALLED_APPS` for convenience.
If your :setting:`INSTALLED_APPS` already contains these apps, feel free to run
:djadmin:`manage.py syncdb` again; you can run that command as many times as
you'd like, and each time it'll only install what's needed.

The :djadmin:`syncdb` command creates the necessary database tables, creates
permission objects for all installed apps that need 'em, and prompts you to
create a superuser account the first time you run it.

Once you've taken those steps, that's it.

Users
=====

.. class:: models.User

API reference
-------------

Fields
~~~~~~

.. class:: models.User

    :class:`~django.contrib.auth.models.User` objects have the following
    fields:

    .. attribute:: models.User.username

        Required. 30 characters or fewer. Alphanumeric characters only
        (letters, digits and underscores).

    .. attribute:: models.User.first_name

        Optional. 30 characters or fewer.

    .. attribute:: models.User.last_name

        Optional. 30 characters or fewer.

    .. attribute:: models.User.email

        Optional. E-mail address.

    .. attribute:: models.User.password

        Required. A hash of, and metadata about, the password. (Django doesn't
        store the raw password.) Raw passwords can be arbitrarily long and can
        contain any character. See the "Passwords" section below.

    .. attribute:: models.User.is_staff

        Boolean. Designates whether this user can access the admin site.

    .. attribute:: models.User.is_active

        Boolean. Designates whether this user account should be considered
        active. We recommend that you set this flag to ``False`` instead of
        deleting accounts; that way, if your applications have any foreign keys
        to users, the foreign keys won't break.

        This doesn't necessarily control whether or not the user can log in.
        Authentication backends aren't required to check for the ``is_active``
        flag, so if you want to reject a login based on ``is_active`` being
        ``False``, it's up to you to check that in your own login view.
        However, the :class:`~django.contrib.auth.forms.AuthenticationForm`
        used by the :func:`~django.contrib.auth.views.login` view *does*
        perform this check, as do the permission-checking methods such as
        :meth:`~models.User.has_perm` and the authentication in the Django
        admin. All of those functions/methods will return ``False`` for
        inactive users.

    .. attribute:: models.User.is_superuser

        Boolean. Designates that this user has all permissions without
        explicitly assigning them.

    .. attribute:: models.User.last_login

        A datetime of the user's last login. Is set to the current date/time by
        default.

    .. attribute:: models.User.date_joined

        A datetime designating when the account was created. Is set to the
        current date/time by default when the account is created.

Methods
~~~~~~~

.. class:: models.User

{'fraction_non_alphanumeric': 0.1043790546802595, 'fraction_numerical': 0.003359592215013902, 'mean_word_length': 3.1786060019361084, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4782635', 'n_tokens_mistral': 2312, 'n_tokens_neox': 2171, 'n_words': 966}