L’authentification livrée avec Django est suffisante dans la plupart des cas, mais vous pouvez rencontrez des besoins qui ne sont pas couverts par la solution proposée par défaut. Afin de personnaliser l’authentification pour les besoins de vos projets, vous devez comprendre quels sont les points d’ancrage permettant d’étendre et de remplacer les composants du système de Django. Ce document fournit des détails sur la façon dont le système d’authentification peut être adapté.
\nLes moteurs d’authentification permettent d’adapter le système lorsque un nom d’utilisateur et un mot de passe stockés dans le modèle d’utilisateur doivent servir à authentifier l’utilisateur avec un autre service que celui par défaut de Django.
\nVous pouvez donner des permissions personnalisées à vos modèles qui peuvent être vérifiées à travers le système d’autorisation de Django.
\nVous pouvez étendre le modèle User par défaut ou le substituer par un tout autre modèle personnalisé.
Dans certaines situations, il peut être nécessaire de se connecter à une autre source d’authentification, c’est-à-dire une autre source de noms d’utilisateur et de mots de passe ou d’autres méthodes d’authentification.
\nPar exemple, votre entreprise possède peut-être déjà une infrastructure LDAP stockant les noms d’utilisateur et mots de passe pour tous ses employés. Il serait fastidieux aussi bien pour l’administrateur réseau que pour les utilisateurs eux-mêmes de devoir gérer des comptes séparés dans LDAP et dans les applications basées sur Django.
\nAinsi, pour faire face à ce genre de situations, le système d’authentification de Django vous permet de brancher d’autres sources d’authentification. Vous pouvez surcharger le système par défaut de Django basé sur la base de données ou vous pouvez utiliser le système par défaut en parallèle avec d’autres systèmes.
\nConsultez la référence sur les moteurs d’authentification pour plus d’informations sur les moteurs d’authentification intégrés à Django.
\nEn arrière-plan, Django maintient une liste de « moteurs d’authentification » qu’il sollicite lors de l’authentification. Lorsque quelqu’un appelle django.contrib.auth.authenticate() comme expliqué ci-dessus dans Comment connecter un utilisateur, Django tente une authentification avec chaque moteur d’authentification. Si la première méthode d’authentification échoue, Django essaie avec la deuxième et ainsi de suite jusqu’à ce que tous les moteurs aient été sollicités.
La liste des moteurs d’authentification à utiliser est définie dans le réglage AUTHENTICATION_BACKENDS. Il doit s’agir d’une liste de chemins Python vers des classes Python qui sont capables d’authentifier des utilisateurs. Ces classes peuvent se trouver n’importe où dans votre chemin Python.
Par défaut, AUTHENTICATION_BACKENDS contient :
["django.contrib.auth.backends.ModelBackend"]\nIl s’agit du moteur d’authentification de base qui vérifie la base de données Django des utilisateurs et interroge les permissions intégrées. Il ne protège pas contre les attaques de force brute et n’utilise pas de mécanisme de « rate limiting » (restriction du nombre de tentatives dans le temps). Vous pouvez soit écrire votre propre mécanisme de restriction dans un moteur d’authentification personnalisé ou utiliser les mécanismes offerts par la plupart des serveurs Web.
\nL’ordre dans la liste AUTHENTICATION_BACKENDS a son importance ; si le même nom d’utilisateur et mot de passe est valable dans plusieurs moteurs, Django s’arrête dès qu’un moteur a accepté les données d’authentification.
Si un moteur génère une exception PermissionDenied, l’authentification échouera immédiatement. Django ne continue pas avec les moteurs suivants.
Un moteur d’authentification est une classe qui implémente obligatoirement deux méthodes : get_user(user_id) et authenticate(request, **credentials). Facultativement, elle peut aussi implémenter un ensemble de méthodes d’autorisation liées aux permissions.
La méthode get_user accepte un paramètre user_id, qui peut être un nom d’utilisateur, un identifiant de base de données ou toute autre valeur, mais qui doit représenter la clé primaire de votre objet utilisateur. Elle renvoie un objet utilisateur ou None.
La méthode authenticate accepte un objet request et des données d’authentification en paramètre. La plupart du temps, elle ressemblera à ceci :
from django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, username=None, password=None):\n # Check the username/password and return a user.\n ...\nMais elle pourrait aussi authentifier avec un jeton, comme ceci :
\nfrom django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, token=None):\n # Check the token and return a user.\n ...\nD’une manière ou d’une autre, authenticate() doit vérifier les données d’authentification qu’elle reçoit et, dans le cas où ces données sont valides, elle doit renvoyer un objet utilisateur correspondant à ces données. Dans le cas contraire, elle doit renvoyer None.
request est un objet HttpRequest et peut valoir None s’il n’a pas été fourni à authenticate() (laquelle le transmet au moteur d’authentification).
Le site d’administration de Django est étroitement lié à l”objet User de Django. Par exemple, pour qu’un utilisateur puisse accéder au site, User.is_staff et User.is_active doivent valoir True (voir AdminSite.has_permission() pour plus de détails).
La meilleure façon de gérer cela est de créer un objet Django User pour chaque utilisateur existant dans votre moteur (par ex. dans votre annuaire LDAP, votre base de données SQL externe, etc.). Vous pouvez soit écrire un script pour le faire de manière anticipée, soit déléguer à votre méthode authenticate la création de l’objet User lors de chaque première connexion.
Voici un exemple de moteur qui s’authentifie en fonction de variables nom d’utilisateur et mot de passe définies dans votre fichier settings.py et crée un objet User de Django lors de la première authentification de l’utilisateur. Dans cet exemple, l’objet User de Django est créé comme superutilisateur ayant un accès complet au site d’administration :
from django.conf import settings\nfrom django.contrib.auth.backends import BaseBackend\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\n\nclass SettingsBackend(BaseBackend):\n """\n Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.\n\n Use the login name and a hash of the password. For example:\n\n ADMIN_LOGIN = 'admin'\n ADMIN_PASSWORD = 'pbkdf2_sha256$30000$Vo0VlMnkR4Bk$qEvtdyZRWTcOsCnI/oQ7fVOu1XAURIZYoOZ3iq8Dr4M='\n """\n\n def authenticate(self, request, username=None, password=None):\n login_valid = settings.ADMIN_LOGIN == username\n pwd_valid = check_password(password, settings.ADMIN_PASSWORD)\n if login_valid and pwd_valid:\n try:\n user = User.objects.get(username=username)\n except User.DoesNotExist:\n # Create a new user. There's no need to set a password\n # because only the password from settings.py is checked.\n user = User(username=username) # is_active defaults to True.\n user.is_staff = True\n user.is_superuser = True\n user.save()\n return user\n return None\n\n def get_user(self, user_id):\n try:\n return User.objects.get(pk=user_id)\n except User.DoesNotExist:\n return None\nPour créer des permissions personnalisées pour un objet modèle donné, utilisez l’attribut Meta permissions du modèle`.
Ce modèle d’exemple Task crée deux permissions personnalisées, c’est-à-dire des actions que les utilisateurs peuvent effectuer ou non avec les instances Task, spécifiquement à votre application :
class Task(models.Model):\n ...\n\n class Meta:\n permissions = [\n ("change_task_status", "Can change the status of tasks"),\n ("close_task", "Can remove a task by setting its status as closed"),\n ]\nLa seule conséquence de ce code est la création de ces permissions supplémentaires lors du lancement de manage.py migrate (la fonction qui crée les permissions est connectée au signal post_migrate). Votre code a ensuite la charge de contrôler la valeur de ces permissions lorsqu’un utilisateur essaie d’accéder à la fonctionnalité fournie par l’application (modification de l’état des tâches ou fermeture des tâches). En poursuivant sur l’exemple précédent, le code suivant contrôle si un utilisateur peut fermer les tâches :
user.has_perm("app.close_task")\nUser existantLien vers cette rubrique#Il existe deux manières d’étendre le modèle User par défaut sans le substituer par votre propre modèle. Si les modifications requises sont purement comportementales et ne nécessitent pas de modifier ce qui est stocké dans la base de données, vous pouvez créer un modèle mandataire basé sur User. Ceci expose toutes les fonctionnalités offertes par les modèles mandataires, y compris l’ordre de tri par défaut, les gestionnaires personnalisés ou les méthodes de modèle personnalisées.
Si vous souhaitez stocker des informations liées au modèle User, vous pouvez utiliser une relation OneToOneField vers un modèle contenant les champs correspondant aux informations supplémentaires. Ce modèle un-à-un est souvent appelé un modèle de profil, car il peut stocker des informations non liées à l’authentification au sujet d’un utilisateur du site. Par exemple, vous pouvez créer un modèle Employee:
from django.contrib.auth.models import User\n\n\nclass Employee(models.Model):\n user = models.OneToOneField(User, on_delete=models.CASCADE)\n department = models.CharField(max_length=100)\nEn supposant qu’il existe un employé Fred Smith référencé à la fois par un modèle User et un modèle Employee, vous pouvez accéder aux informations liées en utilisant les conventions standards des modèles liés de Django :
>>> u = User.objects.get(username="fsmith")\n>>> freds_department = u.employee.department\nPour ajouter les champs du modèle de profil à la page de l’utilisateur dans l’interface d’administration, définissez un InlineModelAdmin (pour cet exemple, nous utiliserons un StackedInline) dans le fichier admin.py de votre application et ajoutez-le à une classe UserAdmin qui sera enregistrée avec la classe User:
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.models import User\n\nfrom my_user_profile_app.models import Employee\n\n\n# Define an inline admin descriptor for Employee model\n# which acts a bit like a singleton\nclass EmployeeInline(admin.StackedInline):\n model = Employee\n can_delete = False\n verbose_name_plural = "employee"\n\n\n# Define a new User admin\nclass UserAdmin(BaseUserAdmin):\n inlines = [EmployeeInline]\n\n\n# Re-register UserAdmin\nadmin.site.unregister(User)\nadmin.site.register(User, UserAdmin)\nCes modèles de profil n’ont aucune particularité, ce ne sont que des modèles Django qui possèdent un lien un-à-un avec un modèle d’utilisateur. En tant que tels, ils ne sont pas automatiquement créés lorsqu’un utilisateur est créé, mais il est possible de profiter du signal django.db.models.signals.post_save pour créer ou mettre à jour les modèles liés selon les besoins.
L’utilisation de modèles liés provoque des requêtes ou des jointures supplémentaires pour récupérer les données liées. En fonction de vos besoins, il peut être préférable d’utiliser un modèle d’utilisateur personnalisé possédant les champs liés supplémentaires. Cependant, des liens existants vers le modèle d’utilisateur par défaut dans les applications de votre projet pourraient justifier la charge supplémentaire sur la base de données.
\nUser personnaliséLien vers cette rubrique#Certains types de projets ont des exigences en terme d’authentification pour lesquelles le modèle User intégré de Django ne convient pas toujours. Par exemple, certains sites préfèrent utiliser l’adresse électronique comme identifiant d’identification plutôt qu’un nom d’utilisateur.
Django permet de surcharger le modèle d’utilisateur par défaut en attribuant une valeur au réglage AUTH_USER_MODEL se référant à un modèle personnalisé :
AUTH_USER_MODEL = "myapp.MyUser"\nCette syntaxe pointée spécifie le attr:~django.apps.AppConfig.label de l’application Django (qui doit figurer dans INSTALLED_APPS) et le nom du modèle Django que vous souhaitez utiliser comme modèle d’utilisateur.
Si vous démarrez un nouveau projet, vous pouvez définir un modèle d’utilisateur personnalisé ayant le même comportement que le modèle par défaut en héritant de AbstractUser:
from django.contrib.auth.models import AbstractUser\n\n\nclass User(AbstractUser):\n pass\nN’oubliez pas de faire pointer AUTH_USER_MODEL vers ce modèle. Faites-le avant de créer les premières migrations ou de lancer manage.py migrate pour la première fois.
De plus, inscrivez le modèle dans le fichier admin.py de l’application :
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin\nfrom .models import User\n\nadmin.site.register(User, UserAdmin)\nLa modification de AUTH_USER_MODEL après avoir créé les tables de base de données est possible mais peut se révéler complexe, car cela affecte les clés étrangères et les relations plusieurs-à-plusieurs, par exemple.
Cette modification ne peut pas être automatisée et nécessite une intervention manuelle sur le schéma, en déplaçant les données depuis l’ancienne table des utilisateurs et peut-être même en réappliquant manuellement certaines migrations. Voir #25313 pour un aperçu des étapes à suivre.
\nEn raison des limites de Django liées à la fonctionnalité de dépendance dynamique pour les modèles remplaçables à chaud, le modèle référencé par AUTH_USER_MODEL doit être créé lors de la première migration de son application (généralement appelée 0001_initial) ; sinon, vous aurez des problèmes de dépendances.
En outre, vous pouvez rencontrer une erreur CircularDependencyError lors de l’exécution des migrations lorsque Django n’est pas en mesure de briser automatiquement la boucle de dépendance en raison de la dépendance dynamique. Si vous rencontrez cette erreur, vous devez rompre la boucle en déplaçant les modèles dont dépend votre modèle d’utilisateur dans une deuxième migration (vous pouvez essayer de faire deux modèles normaux qui ont une clé ForeignKey l’un vers l’autre et voir comment makemigrations résout la dépendance circulaire si vous voulez voir comment cela se passe habituellement).
AUTH_USER_MODELLien vers cette rubrique#Les applications réutilisables ne devraient pas implémenter de modèle d’utilisateur personnalisé. Un projet peut utiliser beaucoup d’applications, et deux applications réutilisables qui implémenteraient chacune un modèle d’utilisateur personnalisé ne pourraient pas être utilisées conjointement. Si vous avez besoin de stocker des informations liées aux utilisateurs dans une application, utilisez une liaison ForeignKey ou OneToOneField vers settings.AUTH_USER_MODEL comme expliqué ci-dessous.
UserLien vers cette rubrique#Si vous référencez directement User (par exemple dans une clé étrangère), votre code ne fonctionnera pas dans des projets où le réglage AUTH_USER_MODEL a été défini à un autre modèle d’utilisateur.
Au lieu de faire directement référence à User, il est préférable de référencer le modèle d’utilisateur en utilisant django.contrib.auth.get_user_model(). Cette méthode renvoie le modèle d’utilisateur actuellement actif, soit le modèle personnalisé s’il a été défini, soit User.
Lorsque vous définissez une clé étrangère ou des relations plusieurs-à-plusieurs vers le modèle d’utilisateur, vous devriez indiquer le modèle personnalisé au moyen du réglage AUTH_USER_MODEL. Par exemple :
from django.conf import settings\nfrom django.db import models\n\n\nclass Article(models.Model):\n author = models.ForeignKey(\n settings.AUTH_USER_MODEL,\n on_delete=models.CASCADE,\n )\nLorsque vous vous connectez aux signaux envoyés par le modèle d’utilisateur, vous devriez indiquer le modèle personnalisé au moyen du réglage AUTH_USER_MODEL. Par exemple :
from django.conf import settings\nfrom django.db.models.signals import post_save\n\n\ndef post_save_receiver(sender, instance, created, **kwargs):\n pass\n\n\npost_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)\nEn règle générale, il est plus facile de se référer au modèle d’utilisateur avec le réglage AUTH_USER_MODEL dans tout code exécuté au moment de l’importation. Cependant, il est aussi possible d’appeler get_user_model() pendant que Django est en train d’importer les modèles. Il est donc possible d’écrire models.ForeignKey(get_user_model(), ...).
Si votre application est testée avec plusieurs modèles d’utilisateur, par exemple en utilisant @override_settings(AUTH_USER_MODEL=...), et que vous conserviez en cache le résultat de get_user_model() dans une variable au niveau du module, il serait alors nécessaire d’écouter le signal setting_changed pour réinitialiser le cache. Par exemple :
from django.apps import apps\nfrom django.contrib.auth import get_user_model\nfrom django.core.signals import setting_changed\nfrom django.dispatch import receiver\n\n\n@receiver(setting_changed)\ndef user_model_swapped(*, setting, **kwargs):\n if setting == "AUTH_USER_MODEL":\n apps.clear_cache()\n from myapp import some_module\n\n some_module.UserModel = get_user_model()\nLorsque vous démarrez votre projet avec votre propre modèle d’utilisateur, prenez le temps de considérer s’il s’agit du bon choix pour votre projet.
\nEn conservant toutes les informations liées à un utilisateur dans un seul modèle, on évite de devoir faire recours à des requêtes de base de données supplémentaires ou plus complexes pour récupérer d’éventuels modèles liés. D’un autre côté, il peut être plus adéquat de stocker les informations utilisateurs spécifiques à une application dans un modèle ayant une relation avec le modèle utilisateur personnalisé. Cela permet à chaque application de définir ses propres exigences en terme de données utilisateurs sans risquer de potentiels conflits ou de casser des comportements attendus par d’autres applications. Cela permet aussi de conserver le modèle utilisateur aussi simple que possible, ciblé sur l’authentification et se limitant aux exigences minimales que Django attend des modèles utilisateurs personnalisés.
\nSi vous utilisez le moteur d’authentification par défaut, le modèle doit alors comporter un seul champ unique pouvant être utilisé pour l’identification. Cela peut être un nom d’utilisateur, une adresse électronique ou tout autre attribut unique. Un champ de nom d’utilisateur non unique est autorisé si vous utilisez un moteur d’authentification personnalisé qui le prend en charge.
\nLa manière la plus simple de construire un modèle d’utilisateur personnalisé en respectant les contraintes est d’hériter de AbstractBaseUser. La classe AbstractBaseUser fournit l’implémentation de base d’un modèle d’utilisateur, y compris les mots de passe hachés et les jetons de réinitialisation des mots de passe. Vous devez ensuite fournir les détails d’implémentation critiques :
Une chaîne contenant le nom du champ du modèle d’utilisateur utilisé comme identifiant unique. C’est normalement quelque chose comme un nom d’utilisateur ou une adresse électronique, ou encore tout autre identifiant unique. Ce champ doit être unique (par ex. avoir unique=True dans sa définition), sauf dans le cas où vous utilisez un moteur d’authentification personnalisé qui sait gérer les noms d’utilisateur non uniques.
Dans l’exemple suivant, le champ identifier est utilisé comme champ d’identification :
class MyUser(AbstractBaseUser):\n identifier = models.CharField(max_length=40, unique=True)\n ...\n USERNAME_FIELD = "identifier"\nUne chaîne décrivant le nom du champ courriel du modèle User. Cette valeur est renvoyée par get_email_field_name().
Une liste de noms de champs qui devront être renseignés lors de la création d’un utilisateur par la commande de gestion createsuperuser. La commande demandera de fournir une valeur pour chacun de ces champs. Cette liste doit contenir tous les champs pour lesquels l’attribut blank est False ou non défini, et peut inclure des champs supplémentaires pour lesquels vous souhaitez que l’utilisateur donne une valeur lorsqu’un utilisateur est créé de manière interactive. REQUIRED_FIELDS n’a aucun effet dans d’autres parties de Django, comme lors de la création d’un utilisateur par l’interface d’administration.
Par exemple, voici la définition partielle d’un modèle d’utilisateur définissant deux champs obligatoires, une date de naissance et une hauteur :
\nclass MyUser(AbstractBaseUser):\n ...\n date_of_birth = models.DateField()\n height = models.FloatField()\n ...\n REQUIRED_FIELDS = ["date_of_birth", "height"]\nUn attribut booléen indiquant si l’utilisateur est considéré comme « actif ». Cet attribut est fournit comme attribut de AbstractBaseUser et valant True par défaut. La manière dont vous allez l’implémenter dépendra des détails des moteurs d’authentification choisis. Consultez la documentation de l’attribut is_active du modèle d’utilisateur intégré pour plus de détails.
Facultatif. Un identifiant formel plus long pour l’utilisateur comme par exemple son nom complet. Si implémenté, il apparaît avec le nom d’utilisateur dans l’historique d’objets dans django.contrib.admin.
Facultatif. Un identifiant informel court pour l’utilisateur comme par exemple son prénom. Si implémenté, il remplace le nom d’utilisateur dans la salutation de l’utilisateur dans l’en-tête du site django.contrib.admin.
Les méthodes et attributs suivants sont disponibles pour chaque sous-classe de AbstractBaseUser:
Renvoie la valeur du champ spécifié dans USERNAME_FIELD.
Normalise le nom d’utilisateur en appelant normalize_username(). Si vous surchargez cette méthode, prenez soin d’appeler super() pour conserver la normalisation.
Renvoie le nom du champ courriel désigné par l’attribut EMAIL_FIELD. Si EMAIL_FIELD n’est pas renseigné, renvoie 'email' par défaut.
Applique la normalisation Unicode NFKC aux noms d’utilisateurs afin que des caractères visuellement identiques avec des points de code Unicode différents soient considérés identiques.
\nAttribut en lecture seule qui vaut toujours True (contrairement à AnonymousUser.is_authenticated qui vaut 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 cet attribut est généralement consulté pour request.user afin de déterminer s’il a été défini par AuthenticationMiddleware (représentant l’utilisateur actuellement connecté), vous devez savoir que cet attribut vaut True pour toute instance de User.
Attribut en lecture seule qui vaut 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 cet attribut.
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 AbstractBaseUser 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().
Version asynchrone: acheck_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).
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 AbstractBaseUser 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.
\nRenvoie False si set_unusable_password() a été appelée pour cet utilisateur.
Renvoie une empreinte HMAC du champ de mot de passe. Utilisé pour Invalidation de session lors du changement de mot de passe.
\nProduit l’empreinte HMAC du champ mot de passe en utilisant SECRET_KEY_FALLBACKS. Utilisé par get_user().
AbstractUser hérite de AbstractBaseUser:
Normalise l’adresse électronique en appelant BaseUserManager.normalize_email(). Si vous surchargez cette méthode, prenez soin d’appeler super() pour conserver la normalisation.
Il faudrait aussi définir un gestionnaire personnalisé pour votre modèle d’utilisateur. Si ce dernier définit les champs username, email, is_staff, is_active, is_superuser, last_login et date_joined comparables au modèle d’utilisateur par défaut de Django, vous pouvez utiliser le gestionnaire UserManager de Django. Cependant, si votre modèle d’utilisateur définit des champs différents, vous devrez définir un gestionnaire personnalisé héritant de BaseUserManager et fournissant deux méthodes supplémentaires :
Le prototype de create_user() doit accepter en paramètre le champ nom d’utilisateur ainsi que tous les champs obligatoires. Par exemple, si votre modèle d’utilisateur utilise email comme champ nom d’utilisateur et que date_of_birth est un champ obligatoire, create_user devrait être définie ainsi :
def create_user(self, email, date_of_birth, password=None):\n # create user here\n ...\nLe prototype de create_superuser() doit accepter en paramètre le champ nom d’utilisateur ainsi que tous les champs obligatoires. Par exemple, si votre modèle d’utilisateur utilise email comme champ nom d’utilisateur et que date_of_birth est un champ obligatoire, create_superuser devrait être définie ainsi :
def create_superuser(self, email, date_of_birth, password=None):\n # create superuser here\n ...\nPour une clé étrangère ForeignKey dans USERNAME_FIELD ou REQUIRED_FIELDS, ces méthodes reçoivent la valeur de to_field (la clé primaire primary_key par défaut) d’une instance existante.
BaseUserManager fournit les méthodes utilitaires suivantes :
Normalise les adresses électroniques en transformant en minuscules la partie nom de domaine de l’adresse.
\nRécupère une instance utilisateur en utilisant le contenu du champ spécifié dans USERNAME_FIELD.
User par défaut de DjangoLien vers cette rubrique#Si le modèle User de Django vous convient entièrement mais que vous voulez ajouter quelques informations de profil supplémentaires, créez une sous-classe de django.contrib.auth.models.AbstractUser et ajoutez vos propres champs de profil. Il est toutefois conseillé de créer un modèle séparé, comme indiqué dans Indication d’une modèle d’utilisateur personnalisé. AbstractUser fournit une implémentation complète du modèle User par défaut sous forme de modèle abstrait.
Les formulaires et les vues intégrés de Django ont certaines attentes à propos du modèle utilisateur avec lequel ils fonctionnent.
\nLes formulaires suivants sont compatibles avec toutes les sous-classes de AbstractBaseUser:
AuthenticationForm: utilise le champ de nom d’utilisateur indiqué par USERNAME_FIELD.
Les formulaires suivants ont certaines attentes à propos du modèle d’utilisateur et peuvent être utilisés tels quels si ces attentes sont remplies :
\nPasswordResetForm: s’attend à ce que le modèle utilisateur possède un champ qui stocke l’adresse électronique de l’utilisateur et nommé selon la valeur renvoyée par get_email_field_name() (email par défaut). Ce champ doit pouvoir être utilisé pour identifier l’utilisateur. Le formulaire compte aussi sur la présence du champ booléen is_active pour empêcher les utilisateurs inactifs de réinitialiser leur mot de passe.
Pour finir, les formulaires suivants sont liés à la classe User et doivent être réécrits ou étendus pour fonctionner avec un modèle d’utilisateur personnalisé :
Si votre modèle d’utilisateur personnalisé est une sous-classe de AbstractUser, vous pouvez alors étendre ces formulaires de cette façon :
from django.contrib.auth.forms import UserCreationForm\nfrom myapp.models import CustomUser\n\n\nclass CustomUserCreationForm(UserCreationForm):\n class Meta(UserCreationForm.Meta):\n model = CustomUser\n fields = UserCreationForm.Meta.fields + ("custom_field",)\ndjango.contrib.adminLien vers cette rubrique#Si vous souhaitez que votre modèle d’utilisateur personnalisé fonctionne également dans l’interface d’administration, celui-ci doit définir certains attributs et méthodes supplémentaires. Ces méthodes permettent au site d’administration de contrôler l’accès de l’utilisateur à son contenu :
\nRenvoie True si l’utilisateur est autorisé à accéder au site d’administration.
Renvoie True si le compte utilisateur est actuellement actif.
Renvoie True si l’utilisateur possède la permission indiquée. Si obj est transmis, la permission doit être vérifiée en relation avec une instance d’objet spécifique.
Renvoie True si l’utilisateur possède la permission d’accéder aux modèles de l’application indiquée.
Il sera aussi nécessaire d’inscrire le modèle d’utilisateur personnalisé à l’interface d’administration. Si votre modèle hérite de django.contrib.auth.models.AbstractUser, vous pouvez utiliser la classe existante de Django django.contrib.auth.admin.UserAdmin. Cependant, si votre modèle hérite de AbstractBaseUser, vous devrez définir une classe ModelAdmin personnalisée. Il est possible d’hériter de la classe django.contrib.auth.admin.UserAdmin, mais il faudra alors surcharger toutes les définitions qui se référent à des champs de django.contrib.auth.models.AbstractUser et qui ne se trouvent pas dans votre classe d’utilisateur personnalisée.
Pour faciliter l’intégration du système des permissions de Django à votre propre classe d’utilisateur, Django propose PermissionsMixin. Il s’agit d’un modèle abstrait que vous pouvez ajouter à la hiérarchie de classes de votre modèle d’utilisateur et qui vous offre ainsi toutes les méthodes et les champs de base de données nécessaires pour la prise en charge du modèle des permissions de Django.
PermissionsMixin contient les méthodes et attributs suivants :
Valeur booléenne. Indique que cet utilisateur possède toutes les permissions sans avoir besoin de les lui attribuer explicitement.
\nRenvoie l’ensemble des permissions (chaînes) que l’utilisateur obtient directement.
\nSi obj est transmis, ne renvoie que les permissions d’utilisateur liées à cet objet spécifique.
Renvoie l’ensemble des permissions (chaînes) que l’utilisateur obtient au travers des groupes auxquels il/elle appartient.
\nSi 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.
\nSi 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 permissions). Si User.is_active et is_superuser sont tous deux à True, cette méthode renvoie toujours True.
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 User.is_active et is_superuser sont tous deux à True, cette méthode renvoie toujours True.
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 paquet donné (l’étiquette d’application Django). Si User.is_active et is_superuser sont tous deux à True, cette méthode renvoie toujours True.
Une limite connue des modèles d’utilisateur personnalisés est que leur installation casse tout modèle mandataire étendant le modèle User. Les modèles mandataires doivent hériter d’une classe de base concrète ; en définissant un modèle d’utilisateur personnalisé, vous supprimez la capacité de Django à identifier de manière fiable la classe de base.
Si votre projet utilise des modèles mandataires, vous devez soit modifier ces modèles afin qu’ils étendent le modèle d’utilisateur utilisé dans votre projet, soit fusionner le comportement du modèle mandataire dans votre sous-classe de User.
Voici un exemple d’application d’utilisateur personnalisé compatible avec l’interface d’administration. Ce modèle d’utilisateur utilise une adresse électronique comme nom d’utilisateur et possède un champ date de naissance obligatoire ; il ne fournit aucun contrôle de permission, excepté un drapeau admin sur le compte utilisateur. Ce modèle est compatible avec tous les formulaires et les vues d’authentification intégrés, à l’exception des formulaires de création d’utilisateur. Cet exemple illustre la façon dont la plupart des composants interagissent, mais il ne s’agit pas de code pouvant être directement copié dans des projets en production.
Ce code pourrait être entièrement placé dans un fichier models.py d’une application d’authentification personnalisée :
from django.db import models\nfrom django.contrib.auth.models import BaseUserManager, AbstractBaseUser\n\n\nclass MyUserManager(BaseUserManager):\n def create_user(self, email, date_of_birth, password=None):\n """\n Creates and saves a User with the given email, date of\n birth and password.\n """\n if not email:\n raise ValueError("Users must have an email address")\n\n user = self.model(\n email=self.normalize_email(email),\n date_of_birth=date_of_birth,\n )\n\n user.set_password(password)\n user.save(using=self._db)\n return user\n\n def create_superuser(self, email, date_of_birth, password=None):\n """\n Creates and saves a superuser with the given email, date of\n birth and password.\n """\n user = self.create_user(\n email,\n password=password,\n date_of_birth=date_of_birth,\n )\n user.is_admin = True\n user.save(using=self._db)\n return user\n\n\nclass MyUser(AbstractBaseUser):\n email = models.EmailField(\n verbose_name="email address",\n max_length=255,\n unique=True,\n )\n date_of_birth = models.DateField()\n is_active = models.BooleanField(default=True)\n is_admin = models.BooleanField(default=False)\n\n objects = MyUserManager()\n\n USERNAME_FIELD = "email"\n REQUIRED_FIELDS = ["date_of_birth"]\n\n def __str__(self):\n return self.email\n\n def has_perm(self, perm, obj=None):\n "Does the user have a specific permission?"\n # Simplest possible answer: Yes, always\n return True\n\n def has_module_perms(self, app_label):\n "Does the user have permissions to view the app `app_label`?"\n # Simplest possible answer: Yes, always\n return True\n\n @property\n def is_staff(self):\n "Is the user a member of staff?"\n # Simplest possible answer: All admins are staff\n return self.is_admin\nPuis, pour inscrire ce modèle d’utilisateur personnalisé dans l’administration de Django, le code suivant doit se trouver dans le fichier admin.py de l’application :
from django import forms\nfrom django.contrib import admin\nfrom django.contrib.auth.models import Group\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.forms import ReadOnlyPasswordHashField\nfrom django.core.exceptions import ValidationError\n\nfrom customauth.models import MyUser\n\n\nclass UserCreationForm(forms.ModelForm):\n """A form for creating new users. Includes all the required\n fields, plus a repeated password."""\n\n password1 = forms.CharField(label="Password", widget=forms.PasswordInput)\n password2 = forms.CharField(\n label="Password confirmation", widget=forms.PasswordInput\n )\n\n class Meta:\n model = MyUser\n fields = ["email", "date_of_birth"]\n\n def clean_password2(self):\n # Check that the two password entries match\n password1 = self.cleaned_data.get("password1")\n password2 = self.cleaned_data.get("password2")\n if password1 and password2 and password1 != password2:\n raise ValidationError("Passwords don't match")\n return password2\n\n def save(self, commit=True):\n # Save the provided password in hashed format\n user = super().save(commit=False)\n user.set_password(self.cleaned_data["password1"])\n if commit:\n user.save()\n return user\n\n\nclass UserChangeForm(forms.ModelForm):\n """A form for updating users. Includes all the fields on\n the user, but replaces the password field with admin's\n disabled password hash display field.\n """\n\n password = ReadOnlyPasswordHashField()\n\n class Meta:\n model = MyUser\n fields = ["email", "password", "date_of_birth", "is_active", "is_admin"]\n\n\nclass UserAdmin(BaseUserAdmin):\n # The forms to add and change user instances\n form = UserChangeForm\n add_form = UserCreationForm\n\n # The fields to be used in displaying the User model.\n # These override the definitions on the base UserAdmin\n # that reference specific fields on auth.User.\n list_display = ["email", "date_of_birth", "is_admin"]\n list_filter = ["is_admin"]\n fieldsets = [\n (None, {"fields": ["email", "password"]}),\n ("Personal info", {"fields": ["date_of_birth"]}),\n ("Permissions", {"fields": ["is_admin"]}),\n ]\n # add_fieldsets is not a standard ModelAdmin attribute. UserAdmin\n # overrides get_fieldsets to use this attribute when creating a user.\n add_fieldsets = [\n (\n None,\n {\n "classes": ["wide"],\n "fields": ["email", "date_of_birth", "password1", "password2"],\n },\n ),\n ]\n search_fields = ["email"]\n ordering = ["email"]\n filter_horizontal = []\n\n\n# Now register the new UserAdmin...\nadmin.site.register(MyUser, UserAdmin)\n# ... and, since we're not using Django's built-in permissions,\n# unregister the Group model from admin.\nadmin.site.unregister(Group)\nFinalement, définissez le modèle personnalisé comme modèle d’utilisateur par défaut dans votre projet au moyen du réglage AUTH_USER_MODEL dans votre fichier settings.py:
AUTH_USER_MODEL = "customauth.MyUser"\n