Autorisation de vue Django – Python réel

By | octobre 28, 2020

Formation gratuite Python

Dans la première partie de cette série, vous avez appris les principes de base des modèles et des vues Django. Dans la partie 2, vous avez découvert la gestion des utilisateurs. Dans ce didacticiel, vous verrez comment combiner ces concepts pour faire Django voir l'autorisation et restreignez ce que les utilisateurs peuvent voir et faire dans vos vues en fonction de leurs rôles.

Permettre aux utilisateurs de se connecter à votre site Web résout deux problèmes: authentification et autorisation. L’authentification consiste à vérifier l’identité d’un utilisateur, en confirmant qu’il est bien ce qu’il prétend être. L'autorisation consiste à décider si un utilisateur est autorisé à effectuer une action. Les deux concepts vont de pair: si une page de votre site Web est réservée aux utilisateurs connectés, les utilisateurs doivent s'authentifier avant de pouvoir être autorisés à consulter la page.

Django fournit des outils pour l'authentification et l'autorisation. L'autorisation de vue Django est généralement effectuée avec décorateurs. Ce tutoriel vous montrera comment utiliser ces décorateurs de vue pour imposer la visualisation autorisée des pages de votre site Django.

À la fin de ce didacticiel, vous saurez comment:

  • Utilisation HttpRequest et HttpRequest.user objets
  • Authentifier et autoriser utilisateurs
  • Différencier entre ordinaire, Personnel, et admin utilisateurs
  • Sécurisez une vue avec le @Connexion requise décorateur
  • Restreindre une vue à différents rôles avec le @user_passes_test décorateur
  • Utilisez le Django cadre de messages pour informer vos utilisateurs

Si vous souhaitez suivre les exemples que vous verrez dans ce didacticiel, vous pouvez télécharger l'exemple de code via le lien ci-dessous:

Commencer

Pour mieux comprendre l'autorisation, vous aurez besoin d'un projet à tester. Le code de ce didacticiel est très similaire à celui présenté dans les parties 1 et 2. Vous pouvez suivre en téléchargeant l'exemple de code à partir du lien ci-dessous:

Tout le code de démonstration a été testé avec Python 3.8 et Django 3.0.7. Cela devrait fonctionner avec d'autres versions, mais il peut y avoir des différences subtiles.

Créer un projet

Tout d'abord, vous devrez créer un nouveau projet Django. Étant donné que Django ne fait pas partie de la bibliothèque standard, il est recommandé d’utiliser un environnement virtuel. Une fois que vous disposez de l'environnement virtuel, vous devez suivre les étapes suivantes:

  1. Installez Django.
  2. Créez un nouveau projet.
  3. Créez une application dans le projet.
  4. Ajoutez un répertoire de modèles au projet.
  5. Créez un superutilisateur de site.

Pour accomplir tout cela, utilisez les commandes suivantes:

$ python -m pip installer Django==3.0.7
$ Blog de django-admin startproject
$ CD Blog
$ python manage.py startapp core
$ modèles mkdir
$ python manage.py migrer
$ python manage.py créeuperuser
Nom d'utilisateur: superutilisateur
Adresse e-mail: superuser@example.com
Mot de passe:
Mot de passe (à nouveau):

Vous avez maintenant un Blog projet, mais vous devez toujours informer Django de l'application que vous avez créée et du nouveau répertoire que vous avez ajouté pour les modèles. Vous pouvez le faire en modifiant le Blog / settings.py fichier, d'abord en modifiant INSTALLED_APPS:

INSTALLED_APPS = [[[[
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "coeur",
]

La ligne en surbrillance indique l'ajout du coeur app dans la liste des applications installées. Une fois que vous avez ajouté l'application, vous devez modifier le MODÈLES déclaration:

MODÈLES = [[[[
    
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [[[[os.chemin.joindre(BASE_DIR, "modèles")],
        "APP_DIRS": Vrai,
        "OPTIONS": 
            "processeurs_contexte": [[[[
                "django.template.context_processors.debug",
                "django.template.context_processors.request",
                "django.contrib.auth.context_processors.auth",
                "django.contrib.messages.context_processors.messages",
            ],
        ,
    ,
]

La ligne en surbrillance indique le changement que vous devez apporter. Il modifie le DIRS liste pour inclure votre modèles dossier. Cela indique à Django où chercher vos modèles.

L'exemple de site avec lequel vous travaillerez est une application de blog de base. le coeur l'application a besoin d'un models.py fichier pour contenir les modèles qui stockent le contenu du blog dans la base de données. Éditer core / models.py et ajoutez ce qui suit:

de django.db importer des modèles

classe Blog(des modèles.Modèle):
    Titre = des modèles.CharField(longueur maximale=50)
    contenu = des modèles.Champ de texte()

Maintenant pour quelques pages Web. Créez deux vues, une pour répertorier tous les blogs et une pour afficher un blog. Le code de vos vues entre core / views.py:

de django.http importer HttpResponse
de raccourcis django. importer rendre, get_object_or_404
de core.models importer Blog

def référencement(demande):
    Les données = 
        "blogs": Blog.objets.tout(),
    

    revenir rendre(demande, "listing.html", Les données)

def view_blog(demande, blog_id):
    Blog = get_object_or_404(Blog, id=blog_id)
    Les données = 
        "Blog": Blog,
    

    revenir rendre(demande, "view_blog.html", Les données)

le référencement() view effectue une requête à la recherche de tous les Blog objets et le transmet au rendre() fonction de raccourci. rendre() prend le demande objet qui fournit un contexte à la vue, le nom d'un modèle à rendre (listing.html), et le Les données objet contenant l'ensemble de requêtes de Blog objets.

le view_blog () vue prend un blog_id comme paramètre et l'utilise pour rechercher les Blog objet. Cet objet est passé comme contexte au view_blog.html modèle à travers le rendre() raccourci.

Il existe trois fichiers de modèle qui vont avec les deux vues. Le premier est un modèle de base contenant des éléments HTML courants. Les deux autres prolongent cette base et correspondent aux vues elles-mêmes. Créer templates / base.html comme suit:

<html>
<corps>

% bloquer contenu %
% bloc d'extrémité contenu %

</corps>
</html>

Ce fichier est ensuite étendu par les modèles utilisés par les vues. le référencement() view utilise un fichier appelé templates / listing.html qui ressemble à ceci:

% étend "base.html" %

% bloquer contenu %
<h1>Liste du blog</h1>
<ul>
% pour Blog dans blogs %
  <li> <une href="% URL 'view_blog' blog.id %">Titre du Blog</une> </li>
% fin pour %
</ul>
% bloc d'extrémité contenu %

Remarquez comment il utilise le blogs ensemble de requêtes envoyé par la vue. L'ensemble de requêtes est bouclé, imprimant le Titre attribut de chacun des Blog objets trouvés. Enfin, pour afficher un blog réel, créez templates / view_blog.html:

% étend "base.html" %

% bloquer contenu %
<h1>Titre du Blog</h1>

blog.content

<heure/>

<une href="% URL 'référencement' %">Tous les blogs</une>
% bloc d'extrémité contenu %

le templates / listing.html et templates / view_blog.html les fichiers utilisent le % url% balise pour rechercher les URL associées au référencement() et view_blog () vues. Ces URL doivent être enregistrées dans Blog / urls.py. Modifiez ce fichier comme suit:

de django.contrib importer admin
de django.urls importer chemin, comprendre
de coeur importer vues comme core_views

urlpatterns = [[[[
    chemin("admin /", admin.site.URL),
    chemin("", core_views.référencement, Nom="référencement"),
    chemin("view_blog // ", core_views.view_blog, Nom="view_blog"),
]

Le défaut urls.py le fichier n’est pas importé comprendre(), notez donc le changement à la deuxième ligne. Le reste des lignes en surbrillance est importé core / views.py et créez les modèles d'URL pour le référencement() et view_blog () afficher les fonctions.

Jusqu'à présent, vous n'avez aucun moyen de créer du contenu. L'administrateur Django fournit un moyen rapide de modifier les objets de modèle. Modifier core / admin.py pour enregistrer le Blog objet:

de django.contrib importer admin
de core.models importer Blog

@admin.S'inscrire(Blog)
classe BlogAdmin(admin.ModelAdmin):
    passer

Tout est maintenant en place. Utilisez les commandes de gestion Django suivantes pour créer et migrer les modèles de base de données et exécuter le serveur:

$ python manage.py makemigrations core
$ python manage.py migrer
$ python manage.py runserver

La dernière commande exécute votre serveur de développement Django. Pendant son exécution, vous pouvez utiliser un navigateur pour visiter http://127.0.0.1:8000/. Vous devriez voir votre référencement page, mais sans aucune donnée.

Ajout de données

Puisque vous n’avez encore rien créé, la page n’affichera que le titre. Visitez l'admin Django à http://127.0.0.1:8000/admin/ et connectez-vous à l'aide des informations d'identification de superutilisateur que vous avez créées.

Une fois à l'intérieur, vous pouvez cliquer sur le Ajouter lien à côté du Blogs objet pour créer des données de test. Alternativement, l'exemple de code a un appareil contenant des exemples de données. Vous pouvez charger les données d'exemple avec le loaddata commande de gestion:

$ python manage.py loaddata core.json

Le fichier fixture contient deux exemples d'entrées de blog. Si vous visitez la page d'accueil du site, il devrait maintenant afficher du contenu.

Détection des utilisateurs connectés et de leurs rôles dans une vue

Chaque vue Django prend au moins un argument, un HttpRequest. La demande contient des informations d'état sur l'utilisateur et la page qu'il visite. Voici quelques informations clés dans la demande:

Attribut La description Exemples
schème Schéma d'URL "http" ou "https"
chemin Partie chemin de l'URL "/ musique / groupes /"
méthode Méthode HTTP utilisée "AVOIR" ou "PUBLIER"
AVOIR Paramètres de chaîne de requête
PUBLIER Champs d'un HTTP POST
utilisateur Objet décrivant l'utilisateur

Django a la capacité d'exécuter du code sur chaque requête via un mécanisme de plugin appelé middleware. le utilisateur l'attribut est ajouté au HttpRequest objet par le Authentification brancher. Ce middleware est activé par défaut lorsque vous créez un nouveau projet, vous n’avez donc rien à faire de spécial pour en profiter. Si vous êtes intéressé par le middleware, l’article Construire un middleware Django en présente les concepts.

Pour voir certains des HttpRequest attributs en action, ajoutez la vue suivante à core / views.py:

def see_request(demande):
    texte = F"" "
                                Quelques attributs de l'objet HttpRequest:

                                schème: demande.schème
                                chemin:   demande.chemin
                                méthode: demande.méthode
                                AVOIR:    demande.AVOIR
                                utilisateur:   demande.utilisateur
                "" "

    revenir HttpResponse(texte, content_type="texte simple")

Maintenant, ajoutez la nouvelle vue à Blog / urls / py:

de django.contrib importer admin
de django.urls importer chemin, comprendre
de coeur importer vues comme core_views

urlpatterns = [[[[
    chemin("admin /", admin.site.URL),
    chemin("", core_views.référencement, Nom="référencement"),
    chemin("view_blog // ", core_views.view_blog, Nom="view_blog"),
    chemin("see_request /", core_views.see_request),
]

Avec cela en place, vous pouvez visiter http://127.0.0.1:8000/see_request/ et voir certains des paramètres de la requête. Si vous ajoutez une chaîne de requête à la fin de l'URL, vous pouvez également voir comment AVOIR travaux. Par exemple, http://127.0.0.1:8000/see_request/?breakfast=spam&lunch=spam donne les résultats suivants:

Certains les attributs de les HttpRequest objet:

schème: http
chemin:   /see_request/
méthode: AVOIR
AVOIR:    <QueryDict: "petit déjeuner": [[[["Spam"], "le déjeuner": [[[["Spam"]>
utilisateur:   Utilisateur anonyme

Qui est Utilisateur anonyme, tu demandes? le HttpRequest.user l'objet est toujours rempli de quelque chose. Si le visiteur de votre site Web ne s'est pas authentifié, alors HttpRequest.user contiendra un Utilisateur anonyme objet. Si vous vous êtes connecté plus tôt pour créer des données, vous verrez peut-être superutilisateur au lieu. Si vous êtes connecté, visitez http://127.0.0.1/admin/logout/, puis revisitez la page pour voir la différence.

Tous les objets utilisateur, y compris Utilisateur anonyme, ont des attributs qui vous donnent plus d'informations sur l'utilisateur. Pour voir comment cela fonctionne, ajoutez le code suivant à core / views.py:

def informations utilisateur(demande):
    texte = F"" "
                                Attributs HttpRequest.user sélectionnés:

                                Nom d'utilisateur:     demande.utilisateur.Nom d'utilisateur
                                is_anonymous: demande.utilisateur.est_anonyme
                                is_staff:     demande.utilisateur.is_staff
                                is_superuser: demande.utilisateur.is_superuser
                                c'est actif:    demande.utilisateur.c'est actif
                "" "

    revenir HttpResponse(texte, content_type="texte simple")

Ajouter cette vue à Blog / urls / py:

de django.contrib importer admin
de django.urls importer chemin, comprendre
de coeur importer vues comme core_views

urlpatterns = [[[[
    chemin("admin /", admin.site.URL),
    chemin("", core_views.référencement, Nom="référencement"),
    chemin("view_blog // ", core_views.view_blog, Nom="view_blog"),
    chemin("see_request /", core_views.see_request),
    chemin("informations utilisateur/", core_views.informations utilisateur),
]

Une fois l'URL ajoutée, vous pouvez visiter http://127.0.0.1/user_info/ pour voir ce qui HttpRequest.user contient. Si vous n'êtes pas connecté, vous verrez le résultat suivant:

Attributs HttpRequest.user sélectionnés:

Nom d'utilisateur:
is_anonymous: Vrai
is_staff: Faux
is_superuser: Faux
is_active: Faux

Connectez-vous à la zone d'administration en utilisant le superutilisateur informations d'identification que vous avez créées en visitant http://127.0.0.1/admin/. Une fois que vous êtes connecté, revenez à /informations utilisateur/ et remarquez la différence:

Attributs HttpRequest.user sélectionnés:

nom d'utilisateur: superutilisateur
is_anonymous: Faux
is_staff: Vrai
is_superuser: Vrai
is_active: Vrai

Avec un utilisateur connecté, est_anonyme changements de Vrai à Faux. le Nom d'utilisateur L'attribut vous indique qui est l'utilisateur. Dans ce cas, vous êtes connecté avec le compte de superutilisateur que vous avez créé à l'aide du manage.py createuperuser commander. le is_staff, is_superuser, et c'est actif les attributs sont maintenant tous Vrai.

Django utilise sessions pour gérer l'état d'un utilisateur. Les sessions sont gérées via un middleware. Vous pouvez en savoir plus sur ces concepts dans la documentation Django sur les sessions et le middleware.

Implémentation de l'autorisation Django View

Créer une vue Django avec autorisation est une question d'inspecter le HttpRequest.user objet et voir si l'utilisateur est autorisé à visiter votre page. Que faites-vous si l'utilisateur n'est pas connecté ou n'y a pas accès?

Si l'utilisateur n'est pas connecté, ce serait bien de l'envoyer à la page de connexion, et quand il aura fini de se connecter, de le ramener là où il se trouvait. Cela implique une bonne dose de logique, mais heureusement, Django est livré avec des outils pour vous aider à le faire rapidement.

Restreindre les vues aux utilisateurs connectés

Django prend en charge différentes manières de contrôler ce que les utilisateurs peuvent voir et faire. Il comprend un mécanisme complet pour les groupes et les autorisations et un système plus léger basé sur les comptes des utilisateurs. Ce tutoriel se concentrera sur ce dernier.

Python a une fonctionnalité appelée décorateurs. Un décorateur est une manière d'encapsuler une fonction avec une autre fonction. Django utilise ces décorateurs pour aider à appliquer l'authentification. Pour en savoir plus sur le fonctionnement des décorateurs, consultez le guide sur les décorateurs Python.

Dans Django, vous utilisez des décorateurs pour envelopper votre vue. Le décorateur est alors appelé avant votre vue et peut empêcher votre vue d'être appelée si nécessaire. Ceci est utile pour l'authentification car il vérifie s'il faut permettre à un utilisateur de réellement visiter la vue. Voici la syntaxe:

de django.contrib.auth.decorators importer Connexion requise

@Connexion requise
def private_place(demande):
    revenir HttpResponse("Shhh, membres seulement!", content_type="texte simple")

Le code ci-dessus montre l'utilisation du @Connexion requise décorateur. Quand le private_place () view est appelée, le Django Connexion requise() La fonction wrapper est appelée en premier. Le décorateur vérifie si un utilisateur est authentifié et si ce n'est pas le cas, il les envoie à la page de connexion. L'URL de la page de connexion est paramétrée avec l'URL actuelle afin qu'elle puisse renvoyer le visiteur à la page initiale.

À voir @Connexion requise en action, ajoutez le code ci-dessus à core / views.py et enregistrez l'URL associée dans Blog / urls / py:

de django.contrib importer admin
de django.urls importer chemin, comprendre
de coeur importer vues comme core_views

urlpatterns = [[[[
    chemin("admin /", admin.site.URL),
    chemin("", core_views.référencement, Nom="référencement"),
    chemin("view_blog // ", core_views.view_blog, Nom="view_blog"),
    chemin("see_request /", core_views.see_request),
    chemin("informations utilisateur/", core_views.informations utilisateur),
    chemin("private_place /", core_views.private_place),
]

Les exemples ci-dessus montrent comment restreindre une vue basée sur une fonction. Si vous utilisez des vues basées sur les classes, Django fournit un mixin LoginRequired pour obtenir le même résultat.

Jusqu'à présent, vous utilisiez le mécanisme d'authentification du site d'administration. Cela ne fonctionne que si vous accédez au site d'administration. Si vous vous y rendez et vous connectez, vous pourrez visiter http://127.0.0.1:8000/private_place/. Cependant, si vous allez directement au private_place () sans vous connecter, vous obtiendrez une erreur.

Django est livré avec des outils d'authentification, mais il ne sait pas à quoi ressemble votre site Web, il n'est donc pas livré avec une page de connexion régulière. Dans la partie 2 de cette série, vous avez appris à créer un modèle de connexion. Vous devrez également le faire pour le projet de blog.

Tout d'abord, ajoutez les URL d'autorisation à Blog / urls.py:

de django.contrib importer admin
de django.urls importer chemin, comprendre
de coeur importer vues comme core_views

urlpatterns = [[[[
    chemin("admin /", admin.site.URL),
    chemin("", core_views.référencement, Nom="référencement"),
    chemin("view_blog // ", core_views.view_blog, Nom="view_blog"),
    chemin("see_request /", core_views.see_request),
    chemin("informations utilisateur/", core_views.informations utilisateur),
    chemin("private_place /", core_views.private_place),
    chemin("comptes/", comprendre("django.contrib.auth.urls")),
]

Cela vous permet de profiter de toutes les vues d’authentification intégrées de Django. Vous aurez également besoin d'un modèle de connexion correspondant. Créer un enregistrement/ sous-dossier dans modèles / puis créez login.html à l'intérieur:

% étend 'base.html' %

% bloquer contenu %
<h1>S'identifier</h1>

<forme méthode="Publier">
    % csrf_token %
     form.as_p 
    <contribution type="soumettre" valeur="S'identifier">
</forme>

<une href="% URL 'référencement' %">Tous les blogs</une>
% bloc d'extrémité %

La redirection de connexion fonctionnera désormais correctement lors de votre visite http://127.0.0.1:8000/private_place/. De plus, en ajoutant django.contrib.auth.urls, tu as maintenant / comptes / déconnexion / disponible aussi.

Restreindre les vues à l'administrateur et au personnel

Vous avez maintenant écrit une vue Django avec autorisation. Mais l'autorisation peut être plus compliquée que de simplement vérifier si un utilisateur est authentifié. Django a trois rôles prêts à l'emploi:

  1. Utilisateur
  2. Personnel
  3. Superutilisateur

le private_place () vue ci-dessus utilise le @Connexion requise décorateur pour voir si l'utilisateur est authentifié et si son compte est actif. Vous pouvez également autoriser en fonction des trois rôles.

Pour jouer avec cette fonctionnalité, vous aurez besoin de quelques comptes utilisateur supplémentaires. Accédez à la zone d'administration en visitant http://127.0.0.1:8000/admin/. Clique le Ajouter bouton à côté du Utilisateurs lien objet. Utilisez cet écran pour ajouter un nouvel utilisateur avec le nom d'utilisateur bob:

Écran d'ajout d'utilisateur de Django admin

Django prêt à l'emploi applique désormais les exigences de mot de passe. Vous devrez utiliser à la fois des lettres et des chiffres dans tout mot de passe que vous créez. Par exemple, vous pouvez utiliser tops3cret comme mot de passe.

Une fois que vous avez créé l'utilisateur, vous serez automatiquement redirigé vers la page de modification de l'utilisateur, où vous pourrez spécifier des détails supplémentaires. Les valeurs par défaut sont assez bonnes pour bob. Faites défiler vers le bas et cliquez sur Enregistrez et ajoutez un autre. Une fois de plus, vous serez invité à créer un utilisateur. Cette fois, créez silvia. Lorsque vous êtes invité à obtenir plus de détails sur Silvia, faites défiler la page jusqu'à la section Autorisations et vérifiez la Statut du personnel case à cocher:

Écran Django Admin Edit User, section Permissions

Avec le jeu d'attributs staff, vous pouvez faire défiler vers le bas et enregistrer ce compte. Vous devriez pouvoir vous connecter à la zone administrative en utilisant soit le superutilisateur ou silvia comptes. En tant que membre du personnel, vous pouvez accéder à la zone d'administration, mais vous ne pourrez rien voir par défaut. Vous n’avez pas d’autorisation.

Vous avez maintenant un utilisateur régulier, un membre du personnel et un superutilisateur. À l'aide de ces trois comptes, essayez de visiter / admin /, / private_place /, et /informations utilisateur/ pour voir les différences.

le @Connexion requise décorateur, c'est tout ou rien: vous êtes connecté ou non. Django a également le @user_passes_test décorateur. Ce décorateur vous permet de spécifier une vérification qui autorise l'utilisateur à entrer si elle est réussie.

Essayez d'ajouter cette vue à core / views.py:

de django.contrib.auth.decorators importer user_passes_test

@user_passes_test(lambda utilisateur: utilisateur.is_staff)
def staff_place(demande):
    revenir HttpResponse("Les employés doivent se laver les mains", content_type="texte simple")

le @user_passes_test decorator prend au moins un paramètre, le test à réussir. Ce test est soit une fonction, soit, plus communément, un lambda. Si vous n’avez pas vu de lambda avant, alors considérez-le comme une fonction miniature et anonyme. Après le lambda mot-clé est le paramètre nommé pour le lambda, qui dans ce cas est utilisateur. À droite du côlon (:) est le test.

Ce test examine le HttpRequest.user.is_staff attribut. Si c'est Vrai, puis le test réussit. Pour plus d'informations sur lambda et comment ils fonctionnent, consultez Comment utiliser les fonctions Python Lambda.

Avec la nouvelle vue en place, mettez à jour votre Blog / urls.py fichier pour l'enregistrer:

de django.contrib importer admin
de django.urls importer chemin, comprendre
de coeur importer vues comme core_views

urlpatterns = [[[[
    chemin("admin /", admin.site.URL),
    chemin("", core_views.référencement, Nom="référencement"),
    chemin("view_blog // ", core_views.view_blog, Nom="view_blog"),
    chemin("see_request /", core_views.see_request),
    chemin("informations utilisateur/", core_views.informations utilisateur),
    chemin("private_place /", core_views.private_place),
    chemin("comptes/", comprendre("django.contrib.auth.urls")),
    chemin("staff_place /", core_views.staff_place),
]

Essayez de visiter http://127.0.0.1:8000/staff_place/ connecté avec différents comptes et voir ce qui se passe. N'oubliez pas que vous pouvez toujours aller à / comptes / déconnexion / pour vous déconnecter de votre compte utilisateur actuel. Voici les résultats:

  • bob ne fait pas partie du personnel, il est donc renvoyé à la page de connexion.
  • silvia est un membre du personnel, afin qu'elle puisse voir la vue.
  • superutilisateur est à la fois un membre du personnel et un super-utilisateur et peut également entrer.

le manage.py createuperuser La commande que vous avez utilisée pour créer le super-utilisateur définit automatiquement les comptes de super-utilisateur comme étant également du personnel.

Sous les couvertures, le @Connexion requise le décorateur appelle en fait le @user_passes_test décorateur et utilise le test suivant:

lambda utilisateur: utilisateur.est_authentifié

Tous les @Connexion requise le décorateur vérifie que l'utilisateur est_authentifié La valeur est Vrai, ce qui sera le cas pour tout compte authentifié.

Essayez d'expérimenter un peu vous-même. Ajoutez d'autres vues ou modifiez le test donné au @user_passes_test décorateur pour voir comment cela affecte le code.

Messagerie d'un utilisateur connecté

Django inclut un mécanisme pour notifier vos utilisateurs. Ceci est lié à leur authentification et peut être utilisé dans n'importe quelle vue Django autorisée. Le framework de messages utilise un middleware pour rendre toutes les notifications en suspens pour l'utilisateur disponibles dans n'importe quelle vue. Par défaut, les messages prennent en charge cinq niveaux:

  1. DÉBOGUER
  2. INFO
  3. SUCCÈS
  4. AVERTISSEMENT
  5. ERREUR

La structure des messages est principalement utilisée pour la communication asynchrone avec l'utilisateur. Par exemple, si une tâche en arrière-plan se passe mal, vous pouvez informer l'utilisateur en envoyant un message avec le ERREUR niveau.

Malheureusement, il n’existe aucune zone dans l’administrateur pour la création de messages. Ils doivent être créés dans le code. Pour illustrer cela, ajoutez le code suivant à votre core / views.py:

de django.contrib importer messages

@Connexion requise
def add_messages(demande):
    Nom d'utilisateur = demande.utilisateur.Nom d'utilisateur
    messages.Ajouter un message(demande, messages.INFO, F"Bonjour Nom d'utilisateur")
    messages.Ajouter un message(demande, messages.AVERTISSEMENT, "DANGER WILL ROBINSON")

    revenir HttpResponse("Messages ajoutés", content_type="texte simple")

Cette vue ajoute deux messages à la session de l'utilisateur connecté, un message d'accueil avec le INFO niveau et une alerte avec le AVERTISSEMENT niveau. messages.add_message () prend trois paramètres:

  1. HttpRequest objet
  2. Niveau de message
  3. Message

Utiliser messages.add_message (), vous devez enregistrer la vue en tant qu'URL:

de django.contrib importer admin
de django.urls importer chemin, comprendre
de coeur importer vues comme core_views

urlpatterns = [[[[
    chemin("admin /", admin.site.URL),
    chemin("", core_views.référencement, Nom="référencement"),
    chemin("view_blog // ", core_views.view_blog, Nom="view_blog"),
    chemin("see_request /", core_views.see_request),
    chemin("informations utilisateur/", core_views.informations utilisateur),
    chemin("private_place /", core_views.private_place),
    chemin("comptes/", comprendre("django.contrib.auth.urls")),
    chemin("staff_place /", core_views.staff_place),
    chemin("add_messages /", core_views.add_messages),
]

Vous pouvez accéder aux messages de votre code en utilisant get_messages () ou directement dans un modèle en utilisant le messages valeur dans le contexte du modèle. Ajoutez le code suivant à templates / listing.html pour afficher les messages adressés à l'utilisateur sur la page de liste du blog:

% étend "base.html" %

% bloquer contenu %
<h1>Liste du blog</h1>

% si messages %
<ul classe="messages" style="background-color: #ccc">
  % pour message dans messages %
    <li % si message.tags % classe=" message.tags " % fin si %>
       message 
    </li>
  % fin pour %
</ul>
% fin si %

<ul>
% pour Blog dans blogs %
  <li> <une href="% URL 'view_blog' blog.id %">Titre du Blog</une> </li>
% fin pour %
</ul>
% bloc d'extrémité contenu %

Le code en surbrillance ci-dessus utilise la liste des messages dans le contexte de modèle qui y est mis par le middleware. S'il y a des messages, une liste HTML non ordonnée est créée avec chacun d'eux.

Visite http://127.0.0.1:8000/add_messages/ pour créer des messages, puis accédez à la page de liste du blog à l'adresse http://127.0.0.1:8000/ de les voir. Actualisez la page et vous remarquerez que les messages ont disparu. Django reconnaît automatiquement le fait que les notifications ont été visualisées et les supprime de la session.

Conclusion

La plupart des sites Web complexes nécessitent des comptes d'utilisateurs. Une fois que vous avez des comptes d'utilisateurs, vous devez limiter les endroits où ils peuvent et ne peuvent pas aller. Django fournit une authentification basée sur les rôles pour vous aider avec ces restrictions.

Dans ce didacticiel, vous avez appris à:

  • Utilisation HttpRequest et HttpRequest.user objets
  • Authentifier et autoriser utilisateurs
  • Différencier entre ordinaire, Personnel, et admin utilisateurs
  • Sécurisez une vue avec le @Connexion requise décorateur
  • Restreindre une vue à différents rôles avec le @user_passes_test décorateur
  • Utilisez le Django cadre de messages pour informer vos utilisateurs

Pour recréer les exemples que vous avez vus ci-dessus, vous pouvez télécharger l'exemple de code sur le lien ci-dessous:

Si trois rôles utilisateur ne suffisent pas à vos besoins, Django est également fourni avec des groupes et des autorisations. Grâce à ces fonctionnalités, vous pouvez aller encore plus loin avec la granularité de votre autorisation. Bon codage!