• 12 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 22/03/2024

Personnalisez le modèle utilisateur

Configurez le projet Django

Avant de nous plonger dans l’implémentation de l’authentification dans Django, nous devons d’abord configurer notre projet et nos applications. 

La vidéo en screencast et le texte du cours contiennent tous deux toutes les étapes nécessaires pour configurer le projet. Elles vous seront probablement familières grâce à vos expériences précédentes avec Django ! Découvrez ces étapes clés en video :

Maintenant que vous avez regardé la vidéo, suivez les étapes dans le texte du cours pour configurer vous-même le projet.

Tout d’abord, créez le répertoire du projet et entrez dedans.

~/  → mkdir fotoblog && cd fotoblog

Maintenant, créez un environnement virtuel Python, activez-le, et installez Django. Créez aussi un fichier  requirements.txt  avec  pip freeze  pour pouvoir recréer l’environnement ailleurs.

~/fotoblog  → python -m venv  ENV
~/fotoblog  → source ENV/bin/activate
(ENV) ~/fotoblog  → pip install django
(ENV) ~/fotoblog → pip freeze > requirements.txt

Notre projet contiendra deux applications : l’une, nommée  authentication, qui gèrera l’authentification et les comptes, et l’autre,  blog  , qui hébergera notre logique de partage de billets de  blog  et de photos.

Démarrons le projet et créons maintenant ces deux applications.

(ENV) ~/fotoblog  → django-admin startproject fotoblog .
(ENV) ~/fotoblog  → python manage.py startapp authentication
(ENV) ~/fotoblog  → python manage.py startapp blog

Ajoutez ces applications aux  INSTALLED_APPS  dans les paramètres.

# fotoblog/settings.py
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'authentication',
    'blog',
]

Nous allons profiter d’être dans les paramètres pour configurer la langue du projet en modifiant la constanteLANGUAGE_CODE.

LANGUAGE_CODE = 'fr-fr'

Configurez le projet en tant que dépôt Git, et effectuez le commit initial.

(ENV) ~/fotoblog  → git init
(ENV) ~/fotoblog  → echo ENV > .gitignore
(ENV) ~/fotoblog  → echo __pycache__ >> .gitignore
(ENV) ~/fotoblog  → echo db.sqlite3 >> .gitignore
(ENV) ~/fotoblog  → # Vous pouvez ajouter d’autres fichiers et répertoires dans le .gitignore ici
(ENV) ~/fotoblog  → git add .
(ENV) ~/fotoblog  → git status
(ENV) ~/fotoblog  → git commit -m “initial commit”

Et voilà, le projet est configuré ! Prochaine étape : mise en place d’un modèle de données pour les utilisateurs.

Découvrez le modèle utilisateur

Par convention, les données concernant un utilisateur individuel sont stockées dans un modèle nomméUser (Utilisateur). Django fournit un modèle `User` par défaut. Ce modèle possède de nombreuses méthodes et fonctionnalités spéciales, en particulier en ce qui concerne l’authentification et les permissions, qui lui permettent de s’intégrer automatiquement au framework Django.

Vous pouvez trouver le modèle  User  par défaut dans  django.contrib.auth.models  .

Voici une vue d’ensemble rapide de certains champs du modèle User :

  • username  (nom d’utilisateur) — utilisé pour se connecter

  • first_name  (prénom)

  • last_name  (nom de famille)

  • email

  • password  (mot de passe) — les mots de passe sont stockés après hachage dans la base de données. Ne sauvegardez jamais de mots de passe en clair.

  • is_staff  (est un membre du personnel) — un booléen ; détermine si un utilisateur peut se connecter au site administrateur Django.

  • is_active  (est actif) — un booléen ; on considère que c’est une meilleure pratique avec Django de signaler que des utilisateurs sont inactifs en réglant cet attribut sur  False  plutôt que de les supprimer.

  • is_superuser  (est un superutilisateur) — un booléen ; les superusers, ou superutilisateurs, obtiennent automatiquement toutes les permissions, telles que l’accès au site administrateur.

Et si ces champs ne correspondent pas à mon cas d’usage ?

Bonne question ! Vous pouvez être dans un cas où vous n’avez pas besoin de tous ces champs… ou, au contraire, vous pourriez avoir besoin de tous ces champs-là et d’autres champs en plus !

Heureusement, vous n’avez pas à vous limiter au modèle par défaut. Voyons comment personnaliser  User  .

Utilisez un modèle utilisateur personnalisé

Même si vous trouvez que le modèle  User  par défaut est tout à fait convenable, je vous conseille de toujours implémenter un modèle  User  personnalisé dans votre projet. Et ce, même s’il est identique au modèle par défaut !

Pourquoi ? Parce qu’il est difficile et compliqué de migrer vers un modèle  User   personnalisé après la configuration de votre site Django et l’exécution de vos migrations initiales. Cela demande beaucoup de migrations délicates et une compréhension en profondeur de SQL. Les projets changent, et les clients modifient les spécifications. Épargnez-vous une migraine et configurez un modèle  User  personnalisé dès le début de votre projet.

Afin de créer un modèle User personnalisé, Django fournit deux classes de base que vous pouvez étendre pour répondre à vos besoins spécifiques :

AbstractUser

La classeAbstractUsercontient tous les champs et les méthodes du  User  par défaut.

Si vous pensez que les fonctionnalités de la classe  User  par défaut répondront à vos besoins à elles seules, alors il vous sera vraiment facile de l’utiliser comme modèle  User  personnalisé :

from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    pass

Ceci fournit tous les champs et fonctionnalités du modèle  User  par défaut, avec la souplesse supplémentaire de pouvoir y ajouter des champs et des méthodes par la suite.

Imaginons, par exemple, que vous vouliez stocker un numéro de compte unique à 10 chiffres pour chaque utilisateur. Pour ce faire, spécifiez-le simplement comme vous le feriez pour un champ de n’importe quel modèle.

class User(AbstractUser):
    account_number =  CharField(max_length=10, unique=True)

Si vous voulez ajouter davantage de champs à la classe  User, vous pouvez les spécifier de la même façon.

Mais que se passe-t-il si je ne veux pas utiliser tous les champs fournis dans la classe  User  par défaut ?

Dans ce cas, vous allez plutôt étendre la classe  AbstractBaseUser  . Regardons cela de plus près.

AbstractBaseUser

La classe AbstractBaseUserne contient aucun champ, excepté  password  (mot de passe). Elle possède aussi une suite de méthodes pour gérer l’authentification (tout comme  AbstractUser).

Lorsque vous étendezAbstractBaseUser, vous devez spécifier tous les champs que vous voulez inclure (sauf  password  ). Il faut aussi un peu de configuration supplémentaire pour qu’elle s’intègre bien au système d’authentification de Django.

Les configurations clés à implémenter avec le modèle  AbstractBaseUser  sont les suivantes :

  • USERNAME_FIELD  — indique le nom du champ devant être utilisé comme identifiant de connexion.

  • EMAIL_FIELD  — indique le nom du champ contenant l’adresse e-mail principale d’un utilisateur ('email' par défaut).

  • REQUIRED_FIELDS  — liste des champs à spécifier obligatoirement lors de l’utilisation de la commande  python manage.py createsuperuser.

  • is_active  — vaut  True  par défaut dans   AbstractBaseUser, mais vous pouvez ajouter votre propre champ si vous voulez gérer les utilisateurs actifs et inactifs. 

Et si je veux utiliser une adresse e-mail pour m’identifier ?

C’est facile ! Configurez simplement la constante  USERNAME_FIELD  sur le champ email. Django exige qu’il soit unique. Si votre classe  User  hérite deAbstractUser,  vous pouvez aussi supprimer le champ  username  en le réglant sur  None.

from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser):
    email = models.EmailField(unique=True)
    username = None

    USERNAME_FIELD = 'email'

Très bien, maintenant que nous avons vu différentes façons d’implémenter un modèle  User  avec Django, faisons-le dans notre application !

Configurez l’application Django avec un modèle utilisateur personnalisé

En général, il est préférable de construire son modèle à partir du modèle AbstractUser, car il s’intégrera automatiquement avec le reste du framework Django et aura la meilleure compatibilité avec des applications tierces.

Pour notre site, nous voulons inclure toutes les fonctionnalités de la classe  User  par défaut. Nous allons donc étendre  AbstractUser. Nous allons aussi ajouter deux champs supplémentaires :

    • un   ImageField  contenant une photo de profil,

    • et   role  , un   CharField, qui différenciera les deux types d’utilisateurs sur notre site, les créateurs et les abonnés.

Découvrez la méthode en vidéo :

Étape 1 : Créez le modèle User  

Ajoutez un modèle  User  dans  authentication.

# authentication/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser):
    
    CREATOR = 'CREATOR'
    SUBSCRIBER = 'SUBSCRIBER'

ROLE_CHOICES = (
    (CREATOR, 'Créateur'),
    (SUBSCRIBER, 'Abonné'),
)
profile_photo = models.ImageField(verbose_name='Photo de profil')
role = models.CharField(max_length=30, choices=ROLE_CHOICES, verbose_name='Rôle')

Étape 2 : Configurez Django pour utiliser un modèle User personnalisé

Tel quel, Django utilise le modèle  User  par défaut pour l’authentification. Vous devez donc dire à Django que vous voulez plutôt utiliser votre propre modèle  User. Pour cela, configurez  AUTH_USER_MODEL  avec votre propre modèle dans les paramètres. Lorsque vous configurez  AUTH_USER_MODEL  , utilisez la notation  '<nom-de-l’app>.<nom-du-modèle>'  , ce qui vous donne :

# fotoblog/settings.py
AUTH_USER_MODEL = 'authentication.User'

Super, maintenant que vous avez configuré votre modèleUser, vous pouvez générer et exécuter les migrations initiales !

Étape 3 : Générez et exécutez les migrations initiales

Commençons par générer les migrations. En faisant cela, vous rencontrerez peut-être cette erreur :

(ENV) ~/fotoblog (master)
→ python manage.py makemigrations
SystemCheckError: System check identified some issues:

ERRORS:
authentication.User.profile_photo: (fields.E210) Cannot use ImageField because Pillow is not installed.
    HINT: Get Pillow at https://pypi.org/project/Pillow/ or run command "python -m pip install Pillow".

Django a besoin du package  Pillow   pour utiliser  ImageField  .  Pillow  est une bibliothèque Python de traitement d’images.

Les versions de Django antérieures à 3.2 n’installent pas automatiquement  Pillow  . Si vous rencontrez ce message, vous devez l’installer avec  pip  et mettre à jour le fichier  requirements.txt, avant de réessayer.

(ENV) ~/fotoblog (master) → pip install Pillow
(ENV) ~/fotoblog (master) → pip freeze > requirements.txt

Génération des migrations :

(ENV) ~/fotoblog (master)
→ python manage.py makemigrations
Migrations for 'authentication':
authentication/migrations/0001_initial.py
- Create model User

Exécution des migrations :

(ENV) ~/fotoblog (master)
→ python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, authentication, contenttypes, sessions

Migrations en cours :

Applying contenttypes.0001_initial... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0001_initial... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying auth.0007_alter_validators_add_error_messages... OK
Applying auth.0008_alter_user_username_max_length... OK
Applying auth.0009_alter_user_last_name_max_length... OK
Applying auth.0010_alter_group_name_max_length... OK
Applying auth.0011_update_proxy_permissions... OK
Applying auth.0012_alter_user_first_name_max_length... OK
Applying authentication.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying sessions.0001_initial... OK

Bravo, vous avez créé un modèle utilisateur personnalisé, généré et exécuté les migrations !

En résumé 

  • Django utilise le modèleUserpour gérer l’authentification. 

  • C’est toujours une bonne idée d’utiliser un modèleUserpersonnalisé dans un projet, même si vous n’avez pas besoin de fonctionnalités supplémentaires, car cela permet de faciliter grandement la personnalisation par la suite. 

  • Vous pouvez étendreAbstractUserpour enrichir le modèleUserpar défaut. 

  • Vous pouvez étendreAbstractBaseUsersi vous voulez encore plus de flexibilité, et définir tous les champs vous-même.

Maintenant que vous pouvez stocker des utilisateurs dans la base de données, essayons de les authentifier sur notre site.

Exemple de certificat de réussite
Exemple de certificat de réussite