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.
Les objets User possèdent les champs suivants :
Obligatoire. Au maximum 30 caractères. Les noms d’utilisateur peuvent contenir des caractères alphanumériques (_, @, +, . et -).
Facultatif. Au maximum 30 caractères.
Facultatif. Au maximum 30 caractères.
Facultatif. Adresse électronique.
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.
Une relation plusieurs-à-plusieurs vers Permission.
Valeur booléenne. Indique si cet utilisateur peut accéder au site d’administration.
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 utilisé par la vue 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() ainsi que l’authentification dans le site d’administration de Django. Toutes ces méthodes/fonctions renvoient False pour les utilisateurs inactifs.
Valeur booléenne. Indique que cet utilisateur possède toutes les permissions sans avoir besoin de les lui attribuer explicitement.
Horodatage de la dernière connexion de l’utilisateur. Défini par défaut à la date/heure actuelle.
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éé.
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.
Renvoie toujours False. C’est une façon de différencier les objets User des objets AnonymousUser. Généralement, il vaut mieux utiliser is_authenticated() que cette méthode.
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 (représentant l’utilisateur actuellement connecté), vuos devez savoir que cette méthode renvoie True pour toute instance de User.
Renvoie first_name et last_name séparés par une espace.
Returns the first_name.
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 n’est pas enregistré par cette méthode.
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).
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() ne renvoie jamais True pour cet utilisateur. L’objet User 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.
Renvoie False si set_unusable_password() a été appelée pour cet utilisateur.
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.
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.
Renvoie True si l’utilisateur possède la permission indiquée, où perm est au format "<étiquette application>.<code permission>" (voir la documentation sur les permissions). 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é.
Renvoie True si l’utilisateur possède toutes les permissions indiquées, où chaque permission est au format "<étiquette application>.<code permission>". 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é.
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.
Envoie un courriel à l’utilisateur. Si from_email vaut None, Django utilise DEFAULT_FROM_EMAIL.
Obsolète depuis la version 1.5: Avec l’introduction des modèles utilisateurs personnalisés, l’utilisation de AUTH_PROFILE_MODULE pour définir un modèle de profil n’est plus pris en charge. Consultez les notes de publication de Django 1.5 pour plus d’informations.
Renvoie un profil spécifique au site pour cet utilisateur. Génère django.contrib.auth.models.SiteProfileNotAvailable si le site actuel ne gère pas les profils ou django.core.exceptions.ObjectDoesNotExist si l’utilisateur ne possède pas de profil.
Le modèle User possède un gestionnaire personnalisé comportant les méthodes utilitaires suivantes (en plus de celles fournies par BaseUserManager) :
Crée, enregistre et renvoie un objet User.
Les attributs username et password sont définis en fonction des paramètres transmis. La partie domaine de email est automatiquement convertie en minuscules et l’attribut is_active de l’objet User renvoyé sera défini à True.
Si aucun mot de passe n’est indiqué, set_unusable_password() est appelée.
Les paramètres nommés extra_fields sont directement transmis à la méthode __init__ de User pour permettre de définir n’importe quel valeur de champ d’un modèle d’utilisateur personnalisé.
Voir Création d’utilisateurs pour un exemple d’utilisation.
Identique à create_user(), mais définit is_staff et is_superuser à True.
django.contrib.auth.models.AnonymousUser est une classe qui implémente l’interface django.contrib.auth.models.User, avec les différences suivantes :
id est toujours None.
is_staff et is_superuser sont toujours False.
is_active est toujours False.
groups et user_permissions sont toujours vides.
is_anonymous() renvoie True au lieu de False.
is_authenticated() renvoie False au lieu de True.
set_password(), check_password(), save() et delete() génèrent l’exception NotImplementedError.
En pratique, vous n’aurez probablement jamais besoin d’utiliser directement des objets AnonymousUser vous-même, mais ils sont utilisés dans les requêtes Web, comme expliqué dans la section suivante.
Les objets Permission possèdent les champs suivants :
Obligatoire. 50 caractères au maximum. Exemple : 'Can vote'.
Obligatoire. Une référence à la table de base de données django_content_type, qui contient un enregistrement pour chaque modèle Django installé.
Obligatoire. 100 caractères au maximum. Exemple : 'can_vote'.
Les objets Permission possèdent les mêmes méthodes d’accès aux données que tout autre modèle Django.
Les objets Group possèdent les champs suivants :
Obligatoire. 80 caractères au maximum. Tous les caractères sont autorisés. Exemple : 'Utilisateurs fantastiques'.
Une relation plusieurs-à-plusieurs vers Permission.
group.permissions = [permission_list]
group.permissions.add(permission, permission, ...)
group.permissions.remove(permission, permission, ...)
group.permissions.clear()
L’infrastructure d’authentification définit les signaux suivants qui peuvent être utilisés comme notification lorsqu’un utilisateur se connecte ou se déconnecte.
Envoyé lorsqu’un utilisateur se connecte avec succès.
Paramètres envoyés avec ce signal :
La classe de l’utilisateur qui vient de se connecter.
L’instance HttpRequest actuelle.
L’instance utilisateur qui vient de se connecter.
Envoyé lorsque la méthode logout est appelée.
Comme ci-dessus : la classe de l’utilisateur qui vient de se déconnecter ou None si l’utilisateur n’était pas authentifié.
L’instance HttpRequest actuelle.
L’instance de l’utilisateur qui vient de se déconnecter ou None si l’utilisateur n’était pas authentifié.
Envoyé lorsque le processus de connexion d’un utilisateur a échoué.
Le nom du module utilisé pour l’authentification.
Un dictionnaire de paramètres nommés contenant les données d’authentification qui ont été transmises à 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.
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 du Guide d’authentification des utilisateurs.
Les moteurs suivants sont disponibles dans django.contrib.auth.backends:
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).
Il gère également le modèle de permissions par défaut tel que défini pour User et PermissionsMixin.
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']. Consultez la documentation sur l’authentification par REMOTE_USER.
Jan 13, 2016