--- title: "django.contrib.auth" version: 1.9 locale: fr source: https://docs.djangoproject.com/fr/1.9/ref/contrib/auth/ canonical: https://djangodocs.dev/fr/1.9/ref/contrib/auth/ --- # `django.contrib.auth` Ce document présente le matériel de référence d’API des composants du système d’authentification de Django. Pour plus de détails sur l’utilisation de ces composants et sur la manière de personnaliser l’authentification et l’autorisation, consultez le [guide thématique sur l’authentification](/fr/1.9/topics/auth/). ## Le modèle `User` ### Champs #### `class models.User` Les objets [`User`](#id0) possèdent les champs suivants : #### `username` Obligatoire. Au maximum 30 caractères. Les noms d’utilisateur peuvent contenir des caractères alphanumériques (`_`, `@`, `+`, `.` et `-`). #### `first_name` Facultatif. Au maximum 30 caractères. #### `last_name` Facultatif. Au maximum 30 caractères. #### `email` Facultatif. Adresse électronique. #### `password` Obligatoire. Une empreinte avec métadonnées du mot de passe (Django ne stocke pas le mot de passe en clair). La longueur des mots de passe réels n’est pas limitée, ni les caractères qu’ils contiennent. Voir la [documentation sur les mots de passe](/fr/1.9/topics/auth/passwords/). #### `groups` Une relation plusieurs-à-plusieurs vers [`Group`](#id5). #### `user_permissions` Une relation plusieurs-à-plusieurs vers [`Permission`](#id2). #### `is_staff` Valeur booléenne. Indique si cet utilisateur peut accéder au site d’administration. #### `is_active` Valeur booléenne. Indique si cet utilisateur doit être considéré comme actif. Nous recommandons de définir ce drapeau à `False` au lieu de supprimer le compte ; ainsi, si vos applications comportent des clés étrangères vers des utilisateurs, les clés étrangères ne seront pas cassées. Ceci ne détermine pas forcément si l’utilisateur peut se connecter ou non. Les moteurs d’authentification ne sont pas obligés de vérifier le drapeau `is_active`, et les moteurs par défaut ne le font pas. Si vous souhaitez refuser une connexion en raison de la valeur `False` de `is_active`, c’est à vous de le faire dans votre propre vue de connexion ou dans votre propre moteur d’authentification. Toutefois, le formulaire [`AuthenticationForm`](/fr/1.9/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm) utilisé par la vue [`login()`](/fr/1.9/topics/auth/default/#django.contrib.auth.views.login) (valeur par défaut) *effectue* lui ce contrôle, comme le font les méthodes de contrôle des permissions telles que [`has_perm()`](#django.contrib.auth.models.User.has_perm) ainsi que l’authentification dans le site d’administration de Django. Toutes ces méthodes/fonctions renvoient `False` pour les utilisateurs inactifs. #### `is_superuser` Valeur booléenne. Indique que cet utilisateur possède toutes les permissions sans avoir besoin de les lui attribuer explicitement. #### `last_login` Horodatage de la dernière connexion de l’utilisateur. > **Changed in Django 1.8** > > Ce champ contient `null` si l’utilisateur ne s’est jamais connecté. Précédemment, il était initialisé avec la date/heure courante. #### `date_joined` Horodatage indiquant la date de création du compte. Défini par défaut à la date/heure du moment où le compte a été créé. ### Méthodes #### `class models.User` #### `get_username()` Renvoie le nom d’utilisateur de cet utilisateur. Comme le modèle `User` peut être substitué, il est préférable d’utiliser cette méthode plutôt que de référencer directement l’attribut `username`. #### `is_anonymous()` Renvoie toujours `False`. C’est une façon de différencier les objets [`User`](#id0) des objets [`AnonymousUser`](#django.contrib.auth.models.AnonymousUser). Généralement, il vaut mieux utiliser [`is_authenticated()`](#django.contrib.auth.models.User.is_authenticated) que cette méthode. #### `is_authenticated()` Renvoie toujours `True` (contrairement à `AnonymousUser.is_authenticated()` qui renvoie toujours `False`). C’est une façon de savoir si l’utilisateur a été authentifié. Aucune permission n’est prise en compte et il n’y a pas de contrôle sur le drapeau `is_active` de l’utilisateur ou sur la validité de la session. Même si cette méthode est généralement appelée sur `request.user` afin de déterminer s’il a été défini par [`AuthenticationMiddleware`](/fr/1.9/ref/middleware/#django.contrib.auth.middleware.AuthenticationMiddleware) (représentant l’utilisateur actuellement connecté), vuos devez savoir que cette méthode renvoie `True` pour toute instance de [`User`](#id0). #### `get_full_name()` Renvoie [`first_name`](#django.contrib.auth.models.User.first_name) et [`last_name`](#django.contrib.auth.models.User.last_name) séparés par une espace. #### `get_short_name()` Renvoie le prénom ([`first_name`](#django.contrib.auth.models.User.first_name)). #### `set_password(raw_password)` Définit le mot de passe de l’utilisateur à la chaîne brute indiquée, en se chargeant du hachage du mot de passe. L’objet [`User`](#id0) n’est pas enregistré par cette méthode. Lorsque `raw_password` vaut `None`, le mot de passe sera défini comme non utilisable, comme si on avait appelé [`set_unusable_password()`](#django.contrib.auth.models.User.set_unusable_password). #### `check_password(raw_password)` Renvoie `True` si la chaîne brute transmise est le mot de passe correct de cet utilisateur (cette méthode se charge du hachage du mot de passe en vue de la comparaison). #### `set_unusable_password()` Marque l’utilisateur comme n’ayant pas de mot de passe défini. Ce n’est pas la même chose que de définir une chaîne vide comme mot de passe. [`check_password()`](#django.contrib.auth.models.User.check_password) ne renvoie jamais `True` pour cet utilisateur. L’objet [`User`](#id0) n’est pas enregistré par cette méthode. Cela peut être utile si le processus d’authentification de votre application se fait par une source externe existante telle qu’un annuaire LDAP. #### `has_usable_password()` Renvoie `False` si [`set_unusable_password()`](#django.contrib.auth.models.User.set_unusable_password) a été appelée pour cet utilisateur. #### `get_group_permissions(obj=None)` Renvoie l’ensemble des permissions (chaînes) que l’utilisateur obtient au travers des groupes auxquels il appartient. Si `obj` est transmis, ne renvoie que les permissions de groupe liées à cet objet spécifique. #### `get_all_permissions(obj=None)` Renvoie l’ensemble des permissions (chaînes) que l’utilisateur obtient directement ou au travers des groupes auxquels il appartient. Si `obj` est transmis, ne renvoie que les permissions liées à cet objet spécifique. #### `has_perm(perm, obj=None)` Renvoie `True` si l’utilisateur possède la permission indiquée, où `perm` est au format `"<étiquette application>."` (voir la documentation sur les [permissions](/fr/1.9/topics/auth/default/#topic-authorization)). Si l’utilisateur est inactif, cette méthode renvoie toujours `False`. Si `obj` est transmis, cette méthode ne contrôle pas la permission au niveau du modèle, mais pour l’objet indiqué. #### `has_perms(perm_list, obj=None)` Renvoie `True` si l’utilisateur possède toutes les permissions indiquées, où chaque permission est au format `"<étiquette application>."`. Si l’utilisateur est inactif, cette méthode renvoie toujours `False`. Si `obj` est transmis, cette méthode ne contrôle pas les permissions au niveau du modèle, mais pour l’objet indiqué. #### `has_module_perms(package_name)` Renvoie `True` si l’utilisateur possède au moins une permission dans le module indiqué (l’étiquette d’application Django). Si l’utilisateur est inactif, cette méthode renvoie toujours `False`. #### `email_user(subject, message, from_email=None, **kwargs)` Envoie un courriel à l’utilisateur. Si `from_email` vaut `None`, Django utilise [`DEFAULT_FROM_EMAIL`](/fr/1.9/ref/settings/#std-setting-DEFAULT_FROM_EMAIL). Tout paramètre `**kwargs` sera transmis à l’appel sous-jacent [`send_mail()`](/fr/1.9/topics/email/#django.core.mail.send_mail). ### Méthodes du gestionnaire #### `class models.UserManager` Le modèle [`User`](#id0) possède un gestionnaire personnalisé comportant les méthodes utilitaires suivantes (en plus de celles fournies par [`BaseUserManager`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.BaseUserManager)) : #### `create_user(username, email=None, password=None, **extra_fields)` Crée, enregistre et renvoie un objet [`User`](#id0). Les attributs [`username`](#django.contrib.auth.models.User.username) et [`password`](#django.contrib.auth.models.User.password) sont définis en fonction des paramètres transmis. La partie domaine de [`email`](#django.contrib.auth.models.User.email) est automatiquement convertie en minuscules et l’attribut [`is_active`](#django.contrib.auth.models.User.is_active) de l’objet [`User`](#id0) renvoyé sera défini à `True`. Si aucun mot de passe n’est indiqué, [`set_unusable_password()`](#django.contrib.auth.models.User.set_unusable_password) est appelée. Les paramètres nommés `extra_fields` sont directement transmis à la méthode `__init__` de la classe [`User`](#id0), de manière à permettre la définition de champs supplémentaires sans restriction dans un [modèle d’utilisateur personnalisé](/fr/1.9/topics/auth/customizing/#auth-custom-user). Voir [Création d’utilisateurs](/fr/1.9/topics/auth/default/#topics-auth-creating-users) pour un exemple d’utilisation. #### `create_superuser(username, email, password, **extra_fields)` Identique à [`create_user()`](#django.contrib.auth.models.UserManager.create_user), mais définit [`is_staff`](#django.contrib.auth.models.User.is_staff) et [`is_superuser`](#django.contrib.auth.models.User.is_superuser) à `True`. ## L’objet `AnonymousUser` #### `class models.AnonymousUser` [`django.contrib.auth.models.AnonymousUser`](#django.contrib.auth.models.AnonymousUser) est une classe qui implémente l’interface [`django.contrib.auth.models.User`](#id0), avec les différences suivantes : - [id](/fr/1.9/topics/db/models/#automatic-primary-key-fields) est toujours `None`. - [`username`](#django.contrib.auth.models.User.username) contient toujours la chaîne vide. - [`get_username()`](#django.contrib.auth.models.User.get_username) renvoie toujours la chaîne vide. - [`is_staff`](#django.contrib.auth.models.User.is_staff) et [`is_superuser`](#django.contrib.auth.models.User.is_superuser) sont toujours `False`. - [`is_active`](#django.contrib.auth.models.User.is_active) est toujours `False`. - [`groups`](#django.contrib.auth.models.User.groups) et [`user_permissions`](#django.contrib.auth.models.User.user_permissions) sont toujours vides. - [`is_anonymous()`](#django.contrib.auth.models.User.is_anonymous) renvoie `True` au lieu de `False`. - [`is_authenticated()`](#django.contrib.auth.models.User.is_authenticated) renvoie `False` au lieu de `True`. - [`set_password()`](#django.contrib.auth.models.User.set_password), [`check_password()`](#django.contrib.auth.models.User.check_password), [`save()`](/fr/1.9/ref/models/instances/#django.db.models.Model.save) et [`delete()`](/fr/1.9/ref/models/instances/#django.db.models.Model.delete) génèrent l’exception [`NotImplementedError`](https://docs.python.org/3/library/exceptions.html#NotImplementedError). > **New in Django 1.8** > > `AnonymousUser.get_username()` a été ajouté pour mieux correspondre à [`django.contrib.auth.models.User`](#id0). En pratique, vous n’aurez probablement jamais besoin d’utiliser directement des objets [`AnonymousUser`](#django.contrib.auth.models.AnonymousUser) vous-même, mais ils sont utilisés dans les requêtes Web, comme expliqué dans la section suivante. ## Le modèle `Permission` #### `class models.Permission` ### Champs Les objets [`Permission`](#id2) possèdent les champs suivants : #### `class models.Permission` #### `name` Obligatoire. 255 caractères au maximum. Exemple : `'Can vote'`. > **Changed in Django 1.8** > > La longueur maximale `max_length` a passé de 50 à 255 caractères. #### `content_type` Obligatoire. Une référence à la table de base de données `django_content_type`, qui contient un enregistrement pour chaque modèle installé. #### `codename` Obligatoire. 100 caractères au maximum. Exemple : `'can_vote'`. ### Méthodes Les objets [`Permission`](#id2) possèdent les mêmes méthodes d’accès aux données que tout autre [modèle Django](/fr/1.9/ref/models/instances/). ## Le modèle `Group` #### `class models.Group` ### Champs Les objets [`Group`](#id5) possèdent les champs suivants : #### `class models.Group` #### `name` Obligatoire. 80 caractères au maximum. Tous les caractères sont autorisés. Exemple : `'Utilisateurs fantastiques'`. #### `permissions` Une relation plusieurs-à-plusieurs vers [`Permission`](#id2). ``` group.permissions = [permission_list] group.permissions.add(permission, permission, ...) group.permissions.remove(permission, permission, ...) group.permissions.clear() ``` ## Signaux de connexion et de déconnexion L’infrastructure d’authentification définit les [signaux](/fr/1.9/topics/signals/) suivants qui peuvent être utilisés comme notification lorsqu’un utilisateur se connecte ou se déconnecte. #### `user_logged_in()` Envoyé lorsqu’un utilisateur se connecte avec succès. Paramètres envoyés avec ce signal : **`sender`** La classe de l’utilisateur qui vient de se connecter. **`request`** L’instance [`HttpRequest`](/fr/1.9/ref/request-response/#django.http.HttpRequest) actuelle. **`user`** L’instance utilisateur qui vient de se connecter. #### `user_logged_out()` Envoyé lorsque la méthode `logout` est appelée. **`sender`** Comme ci-dessus : la classe de l’utilisateur qui vient de se déconnecter ou `None` si l’utilisateur n’était pas authentifié. **`request`** L’instance [`HttpRequest`](/fr/1.9/ref/request-response/#django.http.HttpRequest) actuelle. **`user`** L’instance de l’utilisateur qui vient de se déconnecter ou `None` si l’utilisateur n’était pas authentifié. #### `user_login_failed()` Envoyé lorsque le processus de connexion d’un utilisateur a échoué. **`sender`** Le nom du module utilisé pour l’authentification. **`credentials`** Un dictionnaire de paramètres nommés contenant les données d’authentification qui ont été transmises à [`authenticate()`](/fr/1.9/topics/auth/default/#django.contrib.auth.authenticate) ou à votre propre moteur d’authentification. Les données d’authentification correspondant à certains motifs « sensibles » (par ex. « password ») ne sont pas transmis en clair dans les paramètres du signal. ## Moteurs d’authentification Cette section présente les moteurs d’authentification livrés avec Django. Pour de plus amples informations sur la manière de les utiliser et sur l’écriture de vos propres moteurs d’authentification, consultez la section [Autres sources d’authentification](/fr/1.9/topics/auth/customizing/#authentication-backends) du [Guide d’authentification des utilisateurs](/fr/1.9/topics/auth/). ### Moteurs d’authentification disponibles Les moteurs suivants sont disponibles dans [`django.contrib.auth.backends`](#module-django.contrib.auth.backends): #### `class ModelBackend` Il s’agit du moteur d’authentification utilisé par défaut par Django. Il effectue l’authentification sur la base de l’identifiant d’un utilisateur et de son mot de passe. Pour le modèle d’utilisateur par défaut de Django, l’identifiant de l’utilisateur est le nom d’utilisateur (`username`), pour les modèles d’utilisateur personnalisés, c’est le champ contenu dans `USERNAME_FIELD` (voir [Personnalisation des utilisateurs et de l’authentification](/fr/1.9/topics/auth/customizing/)). Il gère également le modèle de permissions par défaut tel que défini pour [`User`](#id0) et [`PermissionsMixin`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.PermissionsMixin). [`has_perm()`](#django.contrib.auth.backends.ModelBackend.has_perm), [`get_all_permissions()`](#django.contrib.auth.backends.ModelBackend.get_all_permissions), [`get_user_permissions()`](#django.contrib.auth.backends.ModelBackend.get_user_permissions) et [`get_group_permissions()`](#django.contrib.auth.backends.ModelBackend.get_group_permissions) acceptent en paramètre un objet pour des permissions spécifiques à cet objet, mais ce moteur n’implémente pas cette possibilité à part le renvoi d’un ensemble vide de permissions si #### `authenticate(username=None, password=None, **kwargs)` Essaie d’authentifier `username` avec `password` en appelant [`User.check_password`](#django.contrib.auth.models.User.check_password). Si aucun `username` n’est fourni, elle essaie d’obtenir un nom d’utilisateur à partir de `kwargs` avec la clé [`CustomUser.USERNAME_FIELD`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD). Renvoie soit un utilisateur authentifié, soit `None`. #### `get_user_permissions(user_obj, obj=None)` > **New in Django 1.8** Renvoie l’ensemble des chaînes de permissions dont `user_obj` bénéficie à partir de ses propres permissions d’utilisateur. Renvoie un ensemble vide si [`is_anonymous()`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.is_anonymous) ou si [`is_active`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.CustomUser.is_active) vaut `False`. #### `get_group_permissions(user_obj, obj=None)` Renvoie l’ensemble des chaînes de permissions dont `user_obj` bénéficie à partir des permissions des groupes auxquels il appartient. Renvoie un ensemble vide si [`is_anonymous()`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.is_anonymous) ou si [`is_active`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.CustomUser.is_active) vaut `False`. #### `get_all_permissions(user_obj, obj=None)` Renvoie l’ensemble des chaînes de permissions dont `user_obj` bénéficie, que ce soit en son nom propre ou au travers des groupes auxquels il appartient. Renvoie un ensemble vide si [`is_anonymous()`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.is_anonymous) ou si [`is_active`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.CustomUser.is_active) vaut `False`. #### `has_perm(user_obj, perm, obj=None)` Utilise [`get_all_permissions()`](#django.contrib.auth.backends.ModelBackend.get_all_permissions) pour vérifier si `user_obj` possède la chaîne de permission `perm`. Renvoie `False` si l’utilisateur n’est pas [`is_active`](/fr/1.9/topics/auth/customizing/#django.contrib.auth.models.CustomUser.is_active). #### `has_module_perms(self, user_obj, app_label)` Indique si `user_obj` possède au moins une permission pour l’application `app_label`. #### `class RemoteUserBackend` Utilisez ce moteur pour profiter de processus d’authentification externes à Django. Le processus d’authentification utilise les noms d’utilisateur se trouvant dans [`request.META['REMOTE_USER']`](/fr/1.9/ref/request-response/#django.http.HttpRequest.META). Consultez la documentation sur l”[authentification par REMOTE\_USER](/fr/1.9/howto/auth-remote-user/). Pour plus de flexibilité, vous pouvez créer votre propre moteur d’authentification héritant de cette classe et surcharger ces attributs ou méthodes : #### `RemoteUserBackend.create_unknown_user` `True` ou `False`. Détermine si un objet [`User`](#id0) est créé s’il n’est pas trouvé dans la base de données. La valeur par défaut est `True`. #### `RemoteUserBackend.authenticate(remote_user)` Le nom d’utilisateur transmis à `remote_user` est considéré comme sûr. Cette méthode renvoie simplement l’objet `User` ayant le nom d’utilisateur indiqué, créant un nouvel utilisateur si [`create_unknown_user`](#django.contrib.auth.backends.RemoteUserBackend.create_unknown_user) vaut `True`. Renvoie `None` si [`create_unknown_user`](#django.contrib.auth.backends.RemoteUserBackend.create_unknown_user) vaut `False` et un objet `User` ayant le nom d’utilisateur indiqué si ce dernier n’existe pas encore dans la base de données. #### `RemoteUserBackend.clean_username(username)` Procède au nettoyage de `username` (par ex. raccourcissement de l’information DN de LDAP) avant de l’utiliser pour obtenir ou créer un objet [`User`](#id0). Renvoie le nom d’utilisateur nettoyé. #### `RemoteUserBackend.configure_user(user)` Configure un nouvel utilisateur. Cette méthode est appelée immédiatement après la création d’un nouvel utilisateur et peut être utilisée pour effectuer des actions de configuration personnalisées, comme l’attribution de groupes d’utilisateurs en fonction d’attributs d’un répertoire LDAP. Renvoie l’objet utilisateur.