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 User doivent servir à authentifier l’utilisateur avec un autre service que celui par défaut de Django.
Vous 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(**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 User. Elle renvoie un objet User.
La méthode authenticate accepte des données d’authentification en paramètre. La plupart du temps, elle ressemblera à ceci :
class MyBackend(object):\n def authenticate(self, username=None, password=None):\n # Check the username/password and return a User.\n ...\nMais elle pourrait aussi authentifier avec un jeton, comme ceci :
\nclass MyBackend(object):\n def authenticate(self, 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 User correspondant à ces données. Dans le cas contraire, elle doit renvoyer None.
Le site d’administration de Django est étroitement couplé à l’objet User de Django. 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 :
from django.conf import settings\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\nclass SettingsBackend(object):\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, 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. Note that we can set password\n # to anything, because it won't be checked; the password\n # from settings.py will.\n user = User(username=username, password='get from settings.py')\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 trois 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 class Meta:\n permissions = (\n ("view_task", "Can see available tasks"),\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 (affichage de tâches, modification de l’état des tâches, fermeture des tâches). En poursuivant sur l’exemple précédent, le code suivant contrôle si un utilisateur peut voir les tâches :
user.has_perm('app.view_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\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# 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# Define a new User admin\nclass UserAdmin(BaseUserAdmin):\n inlines = (EmployeeInline, )\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 User. 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.
Notez que 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 et que donc, en fonction de vos besoins, il peut être préférable de substituer le modèle User par un modèle possédant les champs supplémentaires. Cependant, des liens existants vers le modèle User par défaut dans les applications de votre projet pourraient justifier la charge supplémentaire sur la base de données.
User 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 User 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 nom 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.
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\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\ndef post_save_receiver(sender, instance, created, **kwargs):\n pass\n\npost_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)\nEn règle générale, vous devez référencer le modèle d’utilisateur avec le réglage AUTH_USER_MODEL dans tout code exécuté au moment de l’importation. get_user_model() ne fonctionne qu’une fois que Django a importé tous les modèles.
Django s’attend à ce qu’un minimum d’exigences soient respectées dans les modèles d’utilisateur 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.
Le modèle doit fournir une manière de décrire l’utilisateur dans une forme « courte » et dans une forme « longue ». L’interprétation la plus courante étant de considérer le prénom comme identifiant « court » et le nom complet comme identifiant « long ». Cependant, il n’y a aucune contrainte sur les valeurs renvoyées par ces deux méthodes ; elles peuvent tout aussi bien renvoyer la même valeur si vous le souhaitez.
La manière la plus simple de construire un modèle d’utilisateur personnalisé en respectant les contraintes est d’hériter de AbstractBaseUser. Cette classe fournit l’implémentation de base d’un modèle User, 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 (c’est-à-dire que unique=True doit apparaître 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'\nUSERNAME_FIELD prend dorénavant en charge les clés ForeignKey. Comme il n’existe pas de moyen de passer des instances de modèles durant le dialogue avec createsuperuser, attendez-vous à ce que l’utilisateur saisisse la valeur de to_field (la clé primaire primary_key par défaut) d’une instance existante.
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']\nREQUIRED_FIELDS prend dorénavant en charge les clés ForeignKey. Comme il n’existe pas de moyen de passer des instances de modèles durant le dialogue avec createsuperuser, attendez-vous à ce que l’utilisateur saisisse la valeur de to_field (la clé primaire primary_key par défaut) d’une instance existante.
Un 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.
Une façon longue d’identifier formellement un utilisateur. Fréquemment interprété comme le nom complet de l’utilisateur, mais cela peut être n’importe quelle chaîne de caractères identifiant la personne.
\nUn identifiant court et informel de l’utilisateur. Fréquemment interprété comme le prénom de l’utilisateur, mais cela peut être n’importe quelle chaîne de caractères identifiant l’utilisateur de manière informelle. Elle peut aussi renvoyer la même valeur que django.contrib.auth.models.User.get_full_name().
Les méthodes suivantes sont disponibles pour chaque sous-classe de AbstractBaseUser:
Renvoie la valeur du champ spécifié dans USERNAME_FIELD.
Renvoie toujours False. C’est une manière de différencier ces objets de AnonymousUser. Généralement, il est préférable d’utiliser la méthode is_authenticated().
Renvoie toujours True. C’est une manière de savoir si l’utilisateur a été authentifié. Cela ne dit rien sur les permissions et ne vérifie pas si l’utilisateur est actif. C’est seulement une indication que l’utilisateur a fourni un nom d’utilisateur et un mot de passe valides.
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().
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.
\nIl faudrait aussi défini un gestionnaire personnalisé pour votre modèle User. Si ce dernier définit les champs username, email, is_staff, is_active, is_superuser, last_login et date_joined comparables au modèle User par défaut de Django, vous pouvez simplement utiliser le gestionnaire UserManager de Django. Cependant, si votre modèle User 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):\n # create superuser here\n ...\nAu contraire de create_user(), create_superuser() doit exiger de l’appelant qu’il fournisse un mot de passe.
BaseUserManager fournit les méthodes utilitaires suivantes :
Normalizes email addresses by lowercasing the domain portion of the\nemail address.
\nRécupère une instance utilisateur en utilisant le contenu du champ spécifié dans USERNAME_FIELD.
Renvoie un mot de passe aléatoire de la longueur indiquée et utilisant les caractères de la chaîne des caractères autorisés. Notez que la valeur par défaut de allowed_chars ne contient pas de lettres pouvant prêter à confusion, comme :
i, l, I et 1 (i minuscule, L minuscule, i majuscule et le chiffre 1)
o, O et 0 (o minuscule, o majuscule et zéro)
User par défaut de DjangoLien vers cette rubrique#Si le modèle User de Django vous convient entièrement et que vous voulez simplement ajouter quelques informations de profil supplémentaires, il suffit d’hériter de django.contrib.auth.models.AbstractUser et d’ajouter vos propres champs de profil. Il est toutefois conseillé de créer un modèle séparé, comme indiqué dans la note « Considérations de conception des modèles » de 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 nommé email permettant d’identifier l’utilisateur et un champ booléen nommé 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 simple 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\nclass CustomUserCreationForm(UserCreationForm):\n\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 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 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 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.
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 réellement 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 simple 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 (\n BaseUserManager, AbstractBaseUser\n)\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):\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 get_full_name(self):\n # The user is identified by their email address\n return self.email\n\n def get_short_name(self):\n # The user is identified by their email address\n return self.email\n\n def __str__(self): # __unicode__ on Python 2\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\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 password1 = forms.CharField(label='Password', widget=forms.PasswordInput)\n password2 = forms.CharField(label='Password confirmation', widget=forms.PasswordInput)\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 forms.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(UserCreationForm, self).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 password hash display field.\n """\n password = ReadOnlyPasswordHashField()\n\n class Meta:\n model = MyUser\n fields = ('email', 'password', 'date_of_birth', 'is_active', 'is_admin')\n\n def clean_password(self):\n # Regardless of what the user provides, return the initial value.\n # This is done here, rather than on the field, because the\n # field does not have access to the initial value\n return self.initial["password"]\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 (None, {\n 'classes': ('wide',),\n 'fields': ('email', 'date_of_birth', 'password1', 'password2')}\n ),\n )\n search_fields = ('email',)\n ordering = ('email',)\n filter_horizontal = ()\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