Ce document présente l’utilisation du système d’authentification de Django dans sa configuration par défaut. Cette configuration a évolué afin de pouvoir répondre aux besoins les plus courants des projets, elle est capable de gérer une large palette de tâches, et elle possède une implémentation soigneuse des mots de passe et des permissions. Pour les projets où les besoins en terme d’authentification divergent de la configuration par défaut, Django permet d’étendre et de personnaliser l’authentification de manière approfondie.
\nL’authentification de Django fournit à la fois l’authentification et l’autorisation, regroupés sous le terme général de système d’authentification, dans la mesure où ces fonctions sont assez étroitement liées.
\nLes objets User se trouvent au cœur du système d’authentification. Ils représentent typiquement les personnes qui interagissent avec votre site et sont utilisés pour activer des fonctionnalités comme la restriction d’accès, l’enregistrement de profils utilisateurs, l’association de contenus avec leur créateur, etc. Une seule classe d’utilisateurs existe dans le système d’authentification de Django ; cela signifie donc que les « super-utilisateurs » ('superusers') ou les membres des équipes d’administration du site ( 'staff') ne sont que des objets utilisateur normaux ayant certains attributs définis, et non pas une classe différente d’objet utilisateur.
Les attributs principaux de l’utilisateur par défaut sont :
\nConsultez la documentation complète de l'API pour une référence exhaustive ; la documentation ci-après est plus orientée sur les tâches.
La manière la plus directe de créer des utilisateurs est d’utiliser la fonction utilitaire create_user():
>>> from django.contrib.auth.models import User\n>>> user = User.objects.create_user("john", "lennon@thebeatles.com", "johnpassword")\n\n# At this point, user is a User object that has already been saved\n# to the database. You can continue to change its attributes\n# if you want to change other fields.\n>>> user.last_name = "Lennon"\n>>> user.save()\nSi vous avez installé l’interface d’administration de Django, vous pouvez aussi créer des utilisateurs interactivement.
\nLes superutilisateurs peuvent être créés à l’aide de la commande createsuperuser:
Linux / macOS
$ python manage.py createsuperuser --username=joe --email=joe@example.com\nWindows
...\\> py manage.py createsuperuser --username=joe --email=joe@example.com\nVous devrez saisir un mot de passe. Après l’avoir fait, l’utilisateur sera immédiatement créé. Si vous omettez les options --username ou --email, vous devrez aussi renseigner ces valeurs.
Django ne stocke pas de mots de passe bruts (en clair) dans le modèle d’utilisateur, mais uniquement une empreinte hachée (voir la documentation sur la façon dont sont gérés les mots de passe pour des détails plus complets). C’est pourquoi il faut éviter de manipuler directement l’attribut password de l’utilisateur et qu’une fonction utilitaire est employée pour créer un utilisateur.
Pour changer le mot de passe d’un utilisateur, vous disposez de plusieurs options :
\nmanage.py changepassword *nom d'utilisateur* offre une méthode permettant de changer le mot de passe d’un utilisateur dans une ligne de commande. Vous serez invité à changer le mot de passe de l’utilisateur indiqué en le saisissant deux fois. Si les deux saisies correspondent, le nouveau mot de passe sera immédiatement défini. Si vous n’indiquez pas de nom d’utilisateur, la commande essaie de changer le mot de passe de l’utilisateur dont le nom correspond à l’utilisateur système en cours.
Il est aussi possible de changer un mot de passe de façon programmatique, en utilisant set_password():
>>> from django.contrib.auth.models import User\n>>> u = User.objects.get(username="john")\n>>> u.set_password("new password")\n>>> u.save()\nSi l’interface d’administration de Django est installée, vous pouvez aussi changer les mots de passe des utilisateurs dans les pages d’administration du système d’authentification.
\nDjango fournit également des vues et des formulaires permettant aux utilisateurs de changer leur propre mot de passe.
\nLe changement de mot de passe d’un utilisateur déconnecte toutes ses sessions. Voir Invalidation de session lors du changement de mot de passe pour plus de détails.
\nVersion asynchrone: aauthenticate()
Utilisez authenticate() pour vérifier un jeu de données d’authentification. Cette méthode accepte les données d’authentification sous forme de paramètres nommés, username et password pour la configuration par défaut, vérifie ces données avec chaque moteur d’authentification et renvoie un objet User si l’authentification est valide pour un des moteurs. Si aucun moteur n’accepte l’authentification ou si un moteur génère PermissionDenied, la méthode renvoie None. Par exemple :
from django.contrib.auth import authenticate\n\nuser = authenticate(username="john", password="secret")\nif user is not None:\n # A backend authenticated the credentials\n ...\nelse:\n # No backend authenticated the credentials\n ...\nrequest est un objet HttpRequest facultatif qui est transmis à la méthode authenticate() des moteurs d’authentification.
Django utilise les sessions et le système de middleware pour brancher le système d’authentification dans les objets requête.
Un attribut request.user et une méthode asynchrone request.auser sont définis sur chaque objet requête pour représenter l’utilisateur actuel. Si cet utilisateur ne s’est pas connecté, cet attribut sera constitué d’une instance de AnonymousUser, sinon il s’agira d’une instance de User.
Vous pouvez les différencier par la méthode is_authenticated, comme ceci :
if request.user.is_authenticated:\n # Do something for authenticated users.\n ...\nelse:\n # Do something for anonymous users.\n ...\nOu dans une vue asynchrone :
\nuser = await request.auser()\nif user.is_authenticated:\n # Do something for authenticated users.\n ...\nelse:\n # Do something for anonymous users.\n ...\nSi vous disposez d’un utilisateur authentifié que vous voulez faire correspondre à la session en cours, utilisez la fonction login().
Version asynchrone : alogin()
Pour connecter un utilisateur à partir d’une vue, utilisez login(). Cette fonction accepte un objet HttpRequest et un objet User. login() enregistre l’identifiant de l’utilisateur dans la session en employant l’infrastructure des sessions de Django.
Notez que toute information définie durant la session anonyme d’un utilisateur est conservée dans la session à la suite du processus de connexion.
\nCet exemple montre comment utiliser à la fois authenticate() et login():
from django.contrib.auth import authenticate, login\n\n\ndef my_view(request):\n username = request.POST["username"]\n password = request.POST["password"]\n user = authenticate(request, username=username, password=password)\n if user is not None:\n login(request, user)\n # Redirect to a success page.\n ...\n else:\n # Return an 'invalid login' error message.\n ...\nLorsqu’un utilisateur se connecte, son identifiant et le moteur utilisé pour son authentification sont enregistrés dans la session de l’utilisateur. Cela permet au même moteur d’authentification de récupérer les détails de l’utilisateur lors d’une prochaine requête. Le moteur d’authentification qui sera enregistré dans la session est choisi comme ceci :
\nSi le paramètre backend factultatif est fourni, c’est celui-là qui est utilisé.
Si un attribut user.backend existe, c’est celui-là qui est utilisé. Cela permet de combiner authenticate() et login(): authenticate() définit l’attribut user.backend sur l’objet utilisateur qu’il renvoie.
S’il n’y a qu’un seul moteur dans AUTHENTICATION_BACKENDS, c’est celui-là qui est utilisé.
Sinon, une exception est produite.
Dans les deux premiers cas, la valeur du paramètre backend ou l’attribut user.backend doit correspondre à une chaîne de chemin pointé (comme la syntaxe dans AUTHENTICATION_BACKENDS), et non pas la classe de moteur réelle.
Version asynchrone : alogout()
Pour déconnecter un utilisateur qui a été connecté par django.contrib.auth.login(), utilisez django.contrib.auth.logout() depuis la vue. Cette fonction accepte un objet HttpRequest et ne renvoie aucune valeur. Exemple :
from django.contrib.auth import logout\n\n\ndef logout_view(request):\n logout(request)\n # Redirect to a success page.\nNotez que logout() ne signale pas d’erreur si l’utilisateur n’était pas connecté.
Lorsque vous appelez logout(), les données de session de la requête en cours sont complètement effacées. Ce comportement empêche une autre personne d’utiliser le même navigateur Web pour se connecter et obtenir accès aux données de session de l’utilisateur précédent. Si vous souhaitez placer des informations dans la session qui doivent être disponibles pour l’utilisateur immédiatement après une déconnexion, faites-le après avoir appelé django.contrib.auth.logout().
La manière directe de limiter l’accès à certaines pages est de vérifier request.user.is_authenticated et de rediriger l’utilisateur vers la page de connexion le cas échéant :
from django.conf import settings\nfrom django.shortcuts import redirect\n\n\ndef my_view(request):\n if not request.user.is_authenticated:\n return redirect(f"{settings.LOGIN_URL}?next={request.path}")\n # ...\n…ou d’afficher un message d’erreur :
\nfrom django.shortcuts import render\n\n\ndef my_view(request):\n if not request.user.is_authenticated:\n return render(request, "myapp/login_error.html")\n # ...\nlogin_requiredLien vers cette rubrique#Comme raccourci, vous pouvez utiliser le décorateur login_required() bien pratique :
from django.contrib.auth.decorators import login_required\n\n\n@login_required\ndef my_view(request): ...\nlogin_required() effectue ceci :
Si l’utilisateur n’est pas connecté, il redirige vers settings.LOGIN_URL en transmettant le chemin absolu dans la chaîne de requête. Exemple : /accounts/login/?next=/polls/3/.
Si l’utilisateur est connecté, il exécute la vue normalement. Le code de la vue peut légitimement considérer l’utilisateur comme connecté.
Par défaut, le chemin vers lequel l’utilisateur doit être redirigé après un processus de connexion réussi est stocké dans le paramètre de chaîne de requête nommé "next". Si vous préférez que ce paramètre soit nommé différemment, login_required() accepte un paramètre facultatif redirect_field_name:
from django.contrib.auth.decorators import login_required\n\n\n@login_required(redirect_field_name="my_redirect_field")\ndef my_view(request): ...\nNotez que si vous indiquez une valeur pour redirect_field_name, il faudra très probablement aussi personnaliser le gabarit de connexion, dans la mesure où la variable de contexte du gabarit qui stocke le chemin de redirection utilise la valeur de redirect_field_name comme clé à la place de "next" (la valeur par défaut).
login_required() accepte également un paramètre facultatif login_url. Exemple :
from django.contrib.auth.decorators import login_required\n\n\n@login_required(login_url="/accounts/login/")\ndef my_view(request): ...\nNotez que si vous ne renseignez pas le paramètre login_url, vous devez vous assurer que le réglage settings.LOGIN_URL et votre vue de connexion sont correctement liés. Par exemple, en utilisant les paramètres par défaut, ajoutez les lignes suivantes dans votre configuration d’URL :
from django.contrib.auth import views as auth_views\n\npath("accounts/login/", auth_views.LoginView.as_view()),\nLe réglage settings.LOGIN_URL accepte également des noms de fonction vue et des motifs d’URL nommés. Cela permet de déplacer librement la vue de connexion dans la configuration d’URL sans avoir besoin de mettre à jour le réglage.
LoginRequiredMixinLien vers cette rubrique#Lors de l’utilisation des vues fondées sur les classes, vous pouvez obtenir le même comportement qu’avec login_required en utilisant LoginRequiredMixin. Cette classe mixin doit se trouver à la position la plus à gauche de la chaîne d’héritage.
Si une vue utilise cette classe mixin, toutes les requêtes par des utilisateurs non authentifiés seront redirigées vers la page de connexion ou traitées comme des erreurs HTTP 403 Forbidden, selon le paramètre raise_exception.
Vous pouvez définir n’importe lequel des paramètres de AccessMixin pour personnaliser le traitement des utilisateurs non authentifiés :
from django.contrib.auth.mixins import LoginRequiredMixin\n\n\nclass MyView(LoginRequiredMixin, View):\n login_url = "/login/"\n redirect_field_name = "redirect_to"\nPour limiter l’accès en fonction d’une certaine permission ou d’un test quelconque, le procédé est presque identique à celui décrit dans la section précédente.
\nVous pouvez effectuer le test sur request.user directement dans la vue. Par exemple, cette vue vérifie que l’utilisateur possède bien une adresse électronique dans le domaine prévu et, dans le cas contraire, redirige vers la page de connexion :
from django.shortcuts import redirect\n\n\ndef my_view(request):\n if not request.user.email.endswith("@example.com"):\n return redirect("/login/?next=%s" % request.path)\n # ...\nComme raccourci, vous pouvez utiliser le décorateur user_passes_test qui procède à une redirection lorsque la fonction décorée renvoie False:
from django.contrib.auth.decorators import user_passes_test\n\n\ndef email_check(user):\n return user.email.endswith("@example.com")\n\n\n@user_passes_test(email_check)\ndef my_view(request): ...\nuser_passes_test() requiert un paramètre : un exécutable acceptant un objet User et renvoyant True si l’utilisateur est autorisé à voir la page. Notez que user_passes_test() ne contrôle pas d’office que l’objet User n’est pas anonyme.
user_passes_test() accepte deux paramètres facultatifs :
login_urlPermet d’indiquer l’URL vers laquelle les utilisateurs ne passant pas le test seront redirigés. Cela peut être une page de connexion, la valeur par défaut étant settings.LOGIN_URL.
redirect_field_nameComme pour login_required(). Si vous définissez ce paramètre à None, il ne sera pas présent dans l’URL, ce qui peut être intéressant si vous redirigez des utilisateurs qui ne passent pas le test vers une page ne servant pas à se connecter et où il n’y a pas de concept de « page suivante ».
Par exemple :
\n@user_passes_test(email_check, login_url="/login/")\ndef my_view(request): ...\nQuand on utilise les vues fondées sur les classes, on peut utiliser la classe UserPassesTestMixin pour faire cela.
Vous devez surcharger la méthode test_func() de la classe pour fournir le test qui sera effectué. De plus, vous pouvez définir n’importe lequel des paramètres de AccessMixin pour personnaliser le traitement des utilisateurs non authentifiés :
from django.contrib.auth.mixins import UserPassesTestMixin\n\n\nclass MyView(UserPassesTestMixin, View):\n def test_func(self):\n return self.request.user.email.endswith("@example.com")\nVous pouvez aussi surcharger la méthode get_test_func() si vous souhaitez que la classe mixin utilise une autre méthode pour cette vérification (au lieu de test_func()).
permission_requiredLien vers cette rubrique#Il est relativement courant de devoir vérifier que l’utilisateur dispose d’une certaine permission. À cet effet, Django fournit un raccourci : le décorateur permission_required():
from django.contrib.auth.decorators import permission_required\n\n\n@permission_required("polls.add_choice")\ndef my_view(request): ...\nComme pour la méthode has_perm(), les noms de permission ont la forme "<étiquette application>.<code permission>" (par ex. polls.add_choice pour une permission d’un modèle de l’application polls).
Le décorateur accepte aussi une liste de permissions, auquel cas l’utilisateur doit posséder toutes les permissions de la liste afin d’avoir accès à la vue.
\nNotez que permission_required() accepte également un paramètre facultatif login_url:
from django.contrib.auth.decorators import permission_required\n\n\n@permission_required("polls.add_choice", login_url="/loginpage/")\ndef my_view(request): ...\nComme pour le décorateur login_required(), la valeur par défaut de login_url est settings.LOGIN_URL.
Si le paramètre raise_exception est présent, le décorateur génère une exception PermissionDenied (permission refusée), déclenchant la vue 403 (HTTP Forbidden) au lieu de rediriger vers la page de connexion.
Si vous souhaitez utiliser raise_exception tout en laissant aux utilisateurs une chance de se connecter, vous pouvez ajouter le décorateur login_required():
from django.contrib.auth.decorators import login_required, permission_required\n\n\n@login_required\n@permission_required("polls.add_choice", raise_exception=True)\ndef my_view(request): ...\nCeci évite aussi une boucle de redirection lorsque redirect_authenticated_user=True dans LoginView et que l’utilisateur connecté ne possède pas toutes les permissions requises.
PermissionRequiredMixinLien vers cette rubrique#Pour appliquer des contrôles de permission aux vues fondées sur les classes, vous pouvez utiliser la classe PermissionRequiredMixin:
Cette classe mixin, tout comme le décorateur permission_required, contrôle si l’utilisateur accédant à une vue possède toutes les permissions indiquées. La permission (ou une itération de permissions) doit être indiquée dans le paramètre permission_required:
from django.contrib.auth.mixins import PermissionRequiredMixin\n\n\nclass MyView(PermissionRequiredMixin, View):\n permission_required = "polls.add_choice"\n # Or multiple of permissions:\n permission_required = ["polls.view_choice", "polls.change_choice"]\nVous pouvez définir n’importe lequel des paramètres de AccessMixin pour personnaliser le traitement des utilisateurs non authentifiés.
Vous pouvez également surcharger ces méthodes :
\nRenvoie une itération de noms de permissions utilisés par la classe mixin. Il s’agit par défaut du contenu de l’attribut permission_required, converti en tuple si nécessaire.
Renvoie une valeur booléenne indiquant si l’utilisateur actuel a la permission d’exécuter la vue décorée. Par défaut, ceci renvoie le résultat de l’appel à has_perms() avec la liste des permissions renvoyées par get_permission_required().
Django fournit plusieurs vues permettant de gérer la connexion, la déconnexion et le traitement des mots de passe. Elles font appel aux formulaires d’authentification intégrés, mais vous pouvez leur transmettre aussi vos propres formulaires.
\nDjango fournit pas de gabarit par défaut pour les vues d’authentification. Vous devez créer vos propres gabarits pour les vues que vous souhaitez utiliser. Le contexte de gabarit est documenté dans chaque vue, voir Toutes les vues d’authentification.
\nIl existe différentes méthodes pour mettre en œuvre ces vues dans votre projet. Le plus simple est d’inclure l’URLconf de django.contrib.auth.urls dans votre propre URLconf, par exemple
urlpatterns = [\n path("accounts/", include("django.contrib.auth.urls")),\n]\nCela comprendra les modèles d’URL suivants :
\naccounts/login/ [name='login']\naccounts/logout/ [name='logout']\naccounts/password_change/ [name='password_change']\naccounts/password_change/done/ [name='password_change_done']\naccounts/password_reset/ [name='password_reset']\naccounts/password_reset/done/ [name='password_reset_done']\naccounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']\naccounts/reset/done/ [name='password_reset_complete']\nLes vues possèdent un nom d’URL pour les référencer plus facilement. Voir la documentation des URL pour plus de détails sur l’utilisation de modèles d’URL nommés.
\nSi vous voulez plus de contrôle sur vos URL, vous pouvez référencer une vue spécifique dans votre URLconf
\nfrom django.contrib.auth import views as auth_views\n\nurlpatterns = [\n path("change-password/", auth_views.PasswordChangeView.as_view()),\n]\nLes vues ont des paramètres optionnels que vous pouvez utiliser pour modifier le comportement de la vue. Par exemple, si vous voulez changer le nom du modèle utilisé par une vue, vous pouvez fournir le paramètre template_name. Une façon de le faire est de fournir des paramètres mot-clé dans l’URLconf, ceux-ci seront transmis à la vue. Par exemple
urlpatterns = [\n path(\n "change-password/",\n auth_views.PasswordChangeView.as_view(template_name="change-password.html"),\n ),\n]\nToutes les vues sont basées sur des classes ce qui permet de les personnaliser facilement par héritage.
\nCeci est une liste de toutes les vues fournies par django.contrib.auth. Pour les détails de l’implémentation, voir Utilisation des vues.
Nom d’URL : login
Consultez la documentation sur les URL pour plus de détails sur l’utilisation des motifs d’URL nommés.
\nMéthodes et attributs
\nLe nom d’un gabarit pour afficher le résultat de la vue de connexion d’un utilisateur. Sa valeur par défaut est registration/login.html.
L’URL vers laquelle rediriger l’utilisateur après la connexion, la valeur par défaut étant LOGIN_REDIRECT_URL.
Le nom d’un champ GET contenant l’URL vers laquelle rediriger après la connexion. Sa valeur par défaut est next. Cela surcharge l’URL get_default_redirect_url() si le paramètre GET indiqué est renseigné.
Un exécutable (typiquement une classe de formulaire) à utiliser pour l’authentification. Sa valeur par défaut est AuthenticationForm.
Un dictionnaire de données de contexte qui sera fusionné avec les données de contexte par défaut transmises au gabarit.
\nUne valeur booléenne indiquant si les utilisateurs authentifiés accédant à la page de connexion sont redirigés comme s’ils venaient de se connecter. La valeur par défaut est False.
Un ensemble set d’hôtes, en plus de request.get_host(), qui sont sûrs comme cible de redirection après la connexion. L’ensemble set est vide par défaut.
Renvoie l’URL vers laquelle rediriger après la connexion. L’implémentation par défaut résout et renvoie next_page si l’attribut est défini ou LOGIN_REDIRECT_URL dans le cas contraire.
Voici ce que fait LoginView:
Quand elle est appelée par GET, elle affiche un formulaire de connexion dont la cible POST envoie vers la même URL. Plus d’infos à ce sujet dans un moment.
Quand elle est appelée par POST avec les données d’authentification d’un utilisateur, elle tente de connecter cet utilisateur. Si l’opération réussit, la vue redirige vers l’URL indiquée dans next. Si next est absent, elle redirige vers settings.LOGIN_REDIRECT_URL (/accounts/profile/ par défaut). Si la connexion échoue, la vue affiche à nouveau le formulaire de connexion.
Il est de votre devoir de fournir le code HTML du gabarit de connexion, nommé registration/login.html par défaut. Ce gabarit reçoit quatre variables de contexte de gabarit :
form: un objet Form représentant le formulaire AuthenticationForm.
next: l’URL vers laquelle rediriger après une connexion réussie. Elle peut aussi contenir une chaîne de requête.
site: le Site actuel, selon le réglage SITE_ID. Si l’application site n’est pas installée, il s’agira d’une instance de RequestSite qui détecte le nom du site et son domaine à partir de l’objet HttpRequest en cours.
site_name: un alias de site.name. Si l’application site n’est pas installée, cette variable contiendra la valeur de request.META['SERVER_NAME']. Pour plus d’informations sur les sites, voir L’infrastructure des « sites ».
Si vous préférez ne pas utiliser le gabarit registration/login.html, vous pouvez renseigner le paramètre template_name via les paramètres supplémentaires de la méthode as_view dans votre configuration d’URL. Par exemple, cette ligne de configuration d’URL force l’utilisation de myapp/login.html:
path("accounts/login/", auth_views.LoginView.as_view(template_name="myapp/login.html")),\nVous pouvez également définir le nom du champ GET contenant l’URL vers laquelle rediriger après la connexion en utiliisant redirect_field_name. Par défaut, ce champ s’appelle next.
Voici un exemple de gabarit registration/login.html comme point de départ. Il compte sur la présence d’un gabarit base.html qui définit un bloc content:
{% extends "base.html" %}\n\n{% block content %}\n\n{% if form.errors %}\n<p>Your username and password didn't match. Please try again.</p>\n{% endif %}\n\n{% if next %}\n {% if user.is_authenticated %}\n <p>Your account doesn't have access to this page. To proceed,\n please login with an account that has access.</p>\n {% else %}\n <p>Please login to see this page.</p>\n {% endif %}\n{% endif %}\n\n<form method="post" action="{% url 'login' %}">\n{% csrf_token %}\n<table>\n<tr>\n <td>{{ form.username.label_tag }}</td>\n <td>{{ form.username }}</td>\n</tr>\n<tr>\n <td>{{ form.password.label_tag }}</td>\n <td>{{ form.password }}</td>\n</tr>\n</table>\n\n<input type="submit" value="login">\n<input type="hidden" name="next" value="{{ next }}">\n</form>\n\n{# Assumes you set up the password_reset view in your URLconf #}\n<p><a href="{% url 'password_reset' %}">Lost password?</a></p>\n\n{% endblock %}\nSi vous avez personnalisé l’authentification (voir Personnalisation de l’authentification), il est possible d’utiliser un formulaire d’authentification personnalisé en définissant l’attribut authentication_form. La méthode __init__() de ce formulaire doit accepter un paramètre nommé request; le formulaire doit également implémenter une méthode get_user() qui renvoie l’objet utilisateur authentifié (cette méthode n’est appelée qu’à la suite d’une validation de formulaire réussie).
Déconnecte un utilisateur avec les requêtes POST.
Nom d’URL : logout
Attributs :
\nL’URL vers laquelle rediriger l’utilisateur après la déconnexion, la valeur par défaut étant LOGOUT_REDIRECT_URL.
Le nom complet d’un gabarit à afficher après la déconnexion d’un utilisateur. Sa valeur par défaut est registration/logged_out.html.
Le nom d’un champ GET contenant l’URL vers laquelle rediriger après la déconnexion. Sa valeur par défaut est 'next'. Cela surcharge l’URL next_page si le paramètre GET indiqué est renseigné.
Un dictionnaire de données de contexte qui sera fusionné avec les données de contexte par défaut transmises au gabarit.
\nUn ensemble set d’hôtes, en plus de request.get_host(), qui sont sûrs comme cible de redirection après la déconnexion. L’ensemble set est vide par défaut.
Contexte de gabarit :
\ntitle: la chaîne « Logged out », traduite.
site: le Site actuel, selon le réglage SITE_ID. Si l’application site n’est pas installée, il s’agira d’une instance de RequestSite qui détecte le nom du site et son domaine à partir de l’objet HttpRequest en cours.
site_name: un alias de site.name. Si l’application site n’est pas installée, cette variable contiendra la valeur de request.META['SERVER_NAME']. Pour plus d’informations sur les sites, voir L’infrastructure des « sites ».
Déconnecte un utilisateur par le type de requête POST, puis redirige vers la page de connexion.
Nom d’URL : aucune URL par défaut
\nParamètres facultatifs :
\nlogin_url: l’URL de la page de connexion vers laquelle rediriger. Si ce paramètre n’est pas renseigné, la valeur par défaut utilisée est settings.LOGIN_URL.
Nom d’URL : password_change
Permet à un utilisateur de changer son mot de passe.
\nAttributs :
\nLe nom complet d’un gabarit à utiliser pour l’affichage du formulaire de changement du mot de passe. Sa valeur par défaut est registration/password_change_form.html si le paramètre n’est pas renseigné.
L’URL vers laquelle rediriger après un changement de mot de passe réussi. Contient 'password_change_done' par défaut.
Un formulaire de changement de mot de passe personnalisé qui doit accepter un paramètre nommé user. Le formulaire est responsable de changer réellement le mot de passe de l’utilisateur. La valeur par défaut est PasswordChangeForm.
Un dictionnaire de données de contexte qui sera fusionné avec les données de contexte par défaut transmises au gabarit.
\nContexte de gabarit :
\nform: le formulaire de changement de mot de passe (voir form_class ci-dessus).
Nom d’URL : password_change_done
La page affichée après qu’un utilisateur a changé son mot de passe.
\nAttributs :
\nLe nom complet d’un gabarit à utiliser. Sa valeur par défaut est registration/password_change_done.html si le paramètre n’est pas renseigné.
Un dictionnaire de données de contexte qui sera fusionné avec les données de contexte par défaut transmises au gabarit.
\nNom d’URL : password_reset
Permet à un utilisateur de réinitialiser son mot de passe en générant un lien à usage unique permettant la réinitialisation du mot de passe. Ce lien est envoyé à l’adresse électronique enregistrée pour cet utilisateur.
\nCette vue envoie un courriel si les conditions suivantes sont réunies :
\nL’adresse électronique fournie existe dans le système.
L’utilisateur qui fait la demande est actif (User.is_active vaut True).
L’utilisateur qui fait la demande possède un mot de passe utilisable. Les utilisateurs marqués avec un mot de passe inutilisable (voir set_unusable_password()) ne sont pas autorisés à demander une réinitialisation de leur mot de passe afin d’éviter un comportement inapproprié lorsqu’une source d’authentification externe est configurée, comme par. ex. LDAP.
Si l’une de ces conditions n’est pas remplie, aucun courriel n’est envoyé, mais l’utilisateur ne reçoit pas non plus de message d’erreur, ceci pour empêcher une divulgation d’information à de potentiels attaquants. Si vous souhaitez fournir un message d’erreur dans cette situation, vous pouvez créer une classe héritant de PasswordResetForm et employer l’attribut form_class.
Attributs :
\nLe nom complet d’un gabarit à utiliser pour l’affichage du formulaire de réinitialisation du mot de passe. Sa valeur par défaut est registration/password_reset_form.html si le paramètre n’est pas renseigné.
Formulaire utilisé pour obtenir l’adresse électronique de l’utilisateur pour lequel le mot de passe doit être réinitialisé. La valeur par défaut est PasswordResetForm.
Le nom complet d’un gabarit à utiliser pour produire le courriel contenant le lien de réinitialisation du mot de passe. Sa valeur par défaut est registration/password_reset_email.html si le paramètre n’est pas renseigné.
Le nom complet d’un gabarit à utiliser pour le sujet du courriel contenant le lien de réinitialisation du mot de passe. Sa valeur par défaut est registration/password_reset_subject.txt si le paramètre n’est pas renseigné.
Instance de la classe qui vérifie le lien à usage unique. La valeur par défaut est default_token_generator qui est une instance de django.contrib.auth.tokens.PasswordResetTokenGenerator.
L’URL vers laquelle rediriger après une demande de réinitialisation de mot de passe réussie. Contient 'password_reet_done' par défaut.
Une adresse électronique valide. Par défaut, Django utilise DEFAULT_FROM_EMAIL.
Un dictionnaire de données de contexte qui sera fusionné avec les données de contexte par défaut transmises au gabarit.
\nLe nom complet d’un gabarit à utiliser pour produire un courriel avec plusieurs parties text/html et contenant le lien de réinitialisation du mot de passe. Par défaut, le courriel n’est pas envoyé au format HTML.
\nUn dictionnaire de données de contexte qui sera disponible dans le gabarit du courriel. Il peut être utilisé pour surcharger les valeurs de contexte de gabarit par défaut énumérées ci-dessous, par ex. domain.
Contexte de gabarit :
\nform: le formulaire de réinitialisation du mot de passe de l’utilisateur (voir form_class ci-dessus).
Contexte de gabarit du courriel :
\nemail: un alias de user.email
user: l’utilisateur User actuel, en accord avec le champ de formulaire email. Seuls les utilisateurs actifs ont la possibilité de réinitialiser leur mot de passe (User.is_active is True).
site_name: un alias de site.name. Si l’application site n’est pas installée, cette variable contiendra la valeur de request.META['SERVER_NAME']. Pour plus d’informations sur les sites, voir L’infrastructure des « sites ».
domain: un alias de site.domain. Si l’application site n’est pas installée, cette variable contiendra la valeur de request.get_host().
protocol: http ou https
uid: la clé primaire de l’utilisateur codée en base64.
token: jeton servant à contrôler la validité du lien de réinitialisation.
Exemple de registration/password_reset_email.html (gabarit de corps de message) :
Someone asked for password reset for email {{ email }}. Follow the link below:\n{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}\nLe gabarit du sujet reçoit le même contexte de gabarit. Le sujet doit être une seule ligne de texte brut.
\nNom d’URL : password_reset_done
La page affichée après qu’un utilisateur a reçu le lien pour réinitialiser son mot de passe. Cette vue est appelée par défaut si la vue PasswordResetView ne possède pas une URL success_url définie explicitement.
Attributs :
\nLe nom complet d’un gabarit à utiliser. Sa valeur par défaut est registration/password_reset_done.html si le paramètre n’est pas renseigné.
Un dictionnaire de données de contexte qui sera fusionné avec les données de contexte par défaut transmises au gabarit.
\nNom d’URL : password_reset_confirm
Affiche un formulaire pour saisir un nouveau mot de passe.
\nParamètres nommés provenant de l’URL :
\nuidb64: l’identifiant de l’utilisateur codé en base 64.
token: jeton servant à contrôler la validité du mot de passe.
Attributs :
\nLe nom complet d’un gabarit à utiliser pour l’affichage de la vue de confirmation du mot de passe. Sa valeur par défaut est registration/password_reset_confirm.html.
Instance de la classe qui vérifie le mot de passe. La valeur par défaut est default_token_generator qui est une instance de django.contrib.auth.tokens.PasswordResetTokenGenerator.
Une valeur booléenne indiquant si l’utilisateur doit être automatiquement authentifié à la suite d’une réinitialisation de mot de passe réussie. Vaut False par défaut.
Un chemin Python vers le moteur d’authentification à utiliser lors d’une authentification si post_reset_login vaut True. Obligatoire seulement si plusieurs moteurs sont configurés dans AUTHENTICATION_BACKENDS. La valeur par défaut est None.
Formulaire utilisé pour définir le mot de passe. La valeur par défaut est SetPasswordForm.
URL vers laquelle rediriger après une réinitialisation de mot de passe. Contient 'password_reset_complete' par défaut.
Un dictionnaire de données de contexte qui sera fusionné avec les données de contexte par défaut transmises au gabarit.
\nParamètre jeton affiché comme composant des URL de réinitialisation de mot de passe. Contient 'set-password' par défaut.
Contexte de gabarit :
\nform: le formulaire de définition du mot de passe du nouvel utilisateur (voir form_class ci-dessus).
validlink: valeur booléenne, True si le lien (combinaison de uidb64 et de token) est valable ou pas encore utilisé.
Nom d’URL : password_reset_complete
Affiche une vue informant l’utilisateur que son mot de passe a été changé avec succès.
\nAttributs :
\nLe nom complet d’un gabarit pour afficher la vue. Sa valeur par défaut est registration/password_reset_complete.html.
Un dictionnaire de données de contexte qui sera fusionné avec les données de contexte par défaut transmises au gabarit.
\nRedirige vers la page de connexion, puis vers une autre URL si la connexion réussit.
\nParamètres obligatoires :
\nnext_page: l’URL vers laquelle rediriger après une connexion réussie.
Paramètres facultatifs :
\nlogin_url: l’URL de la page de connexion vers laquelle rediriger. Si ce paramètre n’est pas renseigné, la valeur par défaut utilisée est settings.LOGIN_URL.
redirect_field_name: le nom d’un champ GET contenant l’URL vers laquelle rediriger après la connexion. Cela surcharge next si le paramètre GET indiqué est renseigné.
Si vous ne souhaitez pas utiliser les vues intégrées mais que vous voulez profiter de ne pas devoir réécrire les formulaires de cette fonctionnalité, le système d’authentification fournit plusieurs formulaires intégrés se trouvant dans django.contrib.auth.forms:
Un formulaire utilisé dans l’interface d’administration pour changer le mot de passe d’un utilisateur.
\nAccepte user comme premier paramètre positionnel.
Un formulaire pour connecter un utilisateur.
\nAccepte request comme premier paramètre positionnel, qui est ensuite stocké dans l’instance de formulaire à disposition des sous-classes.
Par défaut, AuthenticationForm rejette les utilisateurs pour lesquels is_active est à False. Vous pouvez modifier ce comportement pour définir une stratégie personnalisée de détermination des utilisateurs qui peuvent se connecter. Pour cela, utilisez un formulaire personnalisé qui hérite de AuthenticationForm et remplace la méthode confirm_login_allowed(). Cette méthode doit générer une exception ValidationError lorsque l’utilisateur donné n’est pas autorisé à se connecter.
Par exemple, pour permettre à tous les utilisateurs de se connecter, indépendamment de leur statut « actif » :
\nfrom django.contrib.auth.forms import AuthenticationForm\n\n\nclass AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):\n def confirm_login_allowed(self, user):\n pass\n(Dans ce cas, il faudra aussi utiliser un moteur d’authentification qui autorise les utilisateurs inactifs, tel que AllowAllUsersModelBackend.)
Ou pour autoriser uniquement certains utilisateurs actifs à se connecter :
\nclass PickyAuthenticationForm(AuthenticationForm):\n def confirm_login_allowed(self, user):\n if not user.is_active:\n raise ValidationError(\n _("This account is inactive."),\n code="inactive",\n )\n if user.username.startswith("b"):\n raise ValidationError(\n _("Sorry, accounts starting with 'b' aren't welcome here."),\n code="no_b_users",\n )\nUn formulaire pour permettre à un utilisateur de changer son mot de passe.
\nUn formulaire pour générer et envoyer par courriel un lien à usage unique pour réinitialiser le mot de passe d’un utilisateur.
\nUses the arguments to send an EmailMultiAlternatives.\nCan be overridden to customize how the email is sent to the user. If\nyou choose to override this method, be mindful of handling potential\nexceptions raised due to email sending failures.
subject_template_name – le gabarit pour le sujet du message.
email_template_name – le gabarit pour le corps du message.
context – contexte transmis aux gabarits subject_template, email_template et html_email_template (s’il ne vaut pas None).
from_email – l’adresse électronique de l’expéditeur.
to_email – l’adresse électronique du destinataire.
html_email_template_name – le gabarit du corps du message HTML ; vaut None par défaut, auquel cas un courriel en texte pur est envoyé.
Par défaut, save() remplit le context avec les mêmes variables que PasswordResetView transmet à son contexte d’envoi de courriel.
Un formulaire permettant à un utilisateur de changer son mot de passe sans saisir l’ancien mot de passe.
\nUn formulaire utilisé dans l’interface d’administration pour modifier les données d’un utilisateur et ses permissions.
\nUn formulaire ModelForm pour créer un nouvel utilisateur. Il s’agit de la classe de base recommandée pour personnaliser le formulaire de création d’utilisateur.
Il possède trois champs : username (du modèle utilisateur), password1 et password2. Il vérifie que password1 et password2 correspondent, valide le mot de passe en utilisant validate_password() et définit le mot de passe de l’utilisateur avec set_password().
Hérite de BaseUserCreationForm. Pour aider à prévenir la confusion avec des noms comparables, le formulaire n’autorise pas les noms d’utilisateurs qui ne diffèrent que par leur casse.
L’utilisateur actuellement connecté et ses permissions sont disponibles dans le contexte de gabarit lorsque vous utilisez RequestContext.
Lors de la génération d’un RequestContext de gabarit, l’utilisateur actuellement connecté, une instance de User ou de AnonymousUser, est stockée dans la variable de gabarit {{ user }}:
{% if user.is_authenticated %}\n <p>Welcome, {{ user.username }}. Thanks for logging in.</p>\n{% else %}\n <p>Welcome, new user. Please log in.</p>\n{% endif %}\nCette variable de contexte de gabarit n’est pas disponible si RequestContext n’est pas utilisé.
Les permissions de l’utilisateur actuellement connecté sont stockés dans la variable de gabarit {{ perms }}. C’est une instance de django.contrib.auth.context_processors.PermWrapper, un objet mandataire de permissions adapté aux gabarits.
La consultation d’attributs simples de {{ perms }} sous forme de booléen est une méthode mandataire de User.has_module_perms(). Par exemple, pour vérifier si l’utilisateur connecté a au moins une permission dans l’application foo:
{% if perms.foo %}\nLa consultation d’attributs à deux niveaux de {{ perms }} sous forme de booléen est une méthode mandataire de User.has_perm(). Par exemple, pour vérifier si l’utilisateur connecté a la permission foo.add_vote:
{% if perms.foo.add_vote %}\nVoici un exemple plus complet de contrôle de permissions dans un gabarit
\n{% if perms.foo %}\n <p>You have permission to do something in the foo app.</p>\n {% if perms.foo.add_vote %}\n <p>You can vote!</p>\n {% endif %}\n {% if perms.foo.add_driving %}\n <p>You can drive!</p>\n {% endif %}\n{% else %}\n <p>You don't have permission to do anything in the foo app.</p>\n{% endif %}\nIl est aussi possible de consulter les permissions par des instructions {% if in %}. Par exemple :
{% if 'foo' in perms %}\n {% if 'foo.add_vote' in perms %}\n <p>In lookup works, too.</p>\n {% endif %}\n{% endif %}\nQuand django.contrib.admin et django.contrib.auth sont les deux installés, le site d’administration offre une interface pratique pour afficher et gérer les utilisateurs, les groupes et les permissions. Les utilisateurs peuvent être créés et supprimés comme tout autre modèle Django. Des groupes peuvent être créés et des permissions peuvent être attribuées aux utilisateurs et aux groupes. Les modifications de modèles effectuées dans l’administration par les utilisateurs sont également journalisées et affichées.
Vous devriez voir un lien vers « Utilisateurs » dans la section « Auth » de la page d’accueil du site d’administration. La page d’administration « Ajouter un utilisateur » est différente des autres pages d’administration dans la mesure où elle exige que vous saisissiez d’abord un nom d’utilisateur et un mot de passe avant de pouvoir modifier les autres champs de l’utilisateur.
\nNotez également que si vous voulez qu’un utilisateur puisse créer d’autres utilisateurs dans le site d’administration de Django, vous devez lui attribuer la permission d’ajouter des utilisateurs et de modifier des utilisateurs (c’est-à-dire les permissions « Can add user » et « Can change user »). Si un compte utilisateur a la permission d’ajouter des utilisateurs mais pas de les modifier, ce compte ne pourra pas créer d’utilisateurs. Pourquoi ? Parce que si vous avez la permission d’ajouter des utilisateurs, vous avez le pouvoir de créer des superutilisateurs, qui peuvent à leur tour modifier d’autres utilisateurs. Django exige donc à la fois les permissions « ajout » et « modification » comme légère mesure de sécurité.
\nFaites attention à la façon dont vous permettez aux utilisateurs de gérer les autorisations. Si vous donnez à un non-superutilisateur la possibilité d’éditer les utilisateurs, cela revient finalement au même que de lui donner un statut de super-utilisateur, car il sera en mesure d’élever les autorisations des utilisateurs, y compris les siennes !
\nLes mots de passe des utilisateurs ne sont pas affichés dans le site d’administration (ni stockés dans la base de données), mais les détails de stockage des mots de passe sont visibles. Ces informations contiennent un lien vers le formulaire de changement de mot de passe permettant aux administrateurs de changer les mots de passe des utilisateurs.
\n