[MUSIC]
Le serveur API REST Express que nous avons implémenté dans le
module précédent permet à tout utilisateur d'effectuer l'une des opérations GET, POST ou DELETE. Il
n'y a aucun contrôle sur qui peut effectuer cette opération.
Donc, ce qui signifie que,
si vous exécutez un serveur comme celui-ci, alors n'importe qui peut entrer dans votre serveur et
commencer à manipuler les informations qui sont présentes dans votre base de données.
C' est évidemment une situation dangereuse.
La façon dont ce serveur doit être implémenté est que,
vous devez avoir une sorte de restriction sur les
types d'utilisateurs qui seront autorisés à effectuer quels types d'opérations.
Donc peut-être, vous autoriseriez et
un utilisateur autorisé uniquement à effectuer des opérations GET.
Par exemple, si vous voulez qu'un invité puisse voir des
informations sur les plats de votre restaurant ou le menu de votre restaurant,
etc., c'est parfaitement acceptable.
Mais, vous pouvez autoriser seulement un administrateur à entrer et
modifier les informations sur le plat ou à supprimer un plat du menu.
Et aussi mettre à jour un plat existant dans le menu,
ou une promotion, ou les informations sur les leaders dans votre serveur.
Maintenant, vous pouvez également avoir un autre groupe d'utilisateurs qui seront des utilisateurs enregistrés
qui peuvent être autorisés à enregistrer certains de leurs plats comme leurs plats préférés,
et seulement ils seraient en mesure de manipuler la liste de leurs plats préférés.
C' est donc un autre niveau d'autorisation ou
d'authentification que vous devez effectuer.
Ainsi, vous avez différents niveaux d'utilisateurs, et
aussi, selon le type d'opérations qu'ils seraient autorisés à effectuer.
Donc, tout cela signifie que vous avez besoin d'une sorte de sécurité pour être
intégré dans votre serveur.
Nous allons examiner comment nous pouvons authentifier les utilisateurs,
puis décider quel type d'utilisateur est ce client.
Et puis en fonction du type de l'utilisateur,
vous pouvez autoriser l'utilisateur à effectuer certains types d'opérations.
Nous allons commencer par la compréhension de base de ceci, ce que nous appelons
l'authentification de base dans un côté serveur pour
un client, puis, nous allons construire sur cela tout au long de ce module.
Et puis à la fin de ce module, nous finirons avec un mécanisme
, permettant ainsi aux utilisateurs de s'enregistrer eux-mêmes.
Et, les utilisateurs enregistrés peuvent effectuer certaines opérations
qu'un utilisateur non inscrit ne peut pas, et ainsi de suite.
Nous allons donc imposer différents types de contrôles d'accès pour
diverses opérations côté serveur en fonction du type d'utilisateur.
Donc, cela vous définit la perspective, ou
plutôt l'idée de ce que vous allez rencontrer dans ce module.
Commençons par l'authentification de base,
le mécanisme très basique qui nous permettra d'authentifier les utilisateurs.
L' authentification de base dans HTTP est un mécanisme très simple,
qui demandera à l'utilisateur un nom d'utilisateur et un
mot de passe à soumettre avec une demande.
Et il y a une structure spécifique
sur la façon dont ces informations seront envoyées du client vers le côté serveur.
Donc, c'est une question, l'authentification d'accès de base, que HTTP prend en charge,
est une question qui permettra à un serveur de défier un client, et de demander que
le nom d'utilisateur et le mot de passe soient soumis par le client.
Ainsi, le serveur peut défier le client de s'authentifier en tapant ces
informations.
Le client doit envoyer le nom d'utilisateur et
le mot de passe en réponse au défi du côté serveur.
Ainsi, chaque message de requête provenant d'un client
doit inclure la forme codée du nom d'utilisateur et
du mot de passe dans l'en-tête de requête qui va du client au côté serveur.
Ainsi, lorsque le serveur reçoit la demande,
le serveur extrait ces informations de l'en-tête de requête du client.
Et puis, utilisez cela pour authentifier le client avant
d'autoriser l'accès aux différentes opérations côté serveur.
Alors, comment fonctionne cette authentification ?
Si un client envoie une requête au serveur et que
cette demande client n'inclut pas la formation d'autorisation, alors le serveur
conteste le client, il demande au client de soumettre ces informations.
Le serveur défie le client en incluant
un en-tête dans le message de réponse entrant.
L' en-tête avec le type WW-Authenticate,
puis la deuxième partie où il spécifie le type est où il
spécifiera le type d'authentification que le client doit soumettre.
Et nous allons commencer par la compréhension de l'authentification de base ici.
Et notez également que le message de réponse contiendra un code d'erreur 401,
qui est non autorisé, ce qui signifie non autorisé.
Ainsi, lorsque la réponse revient du côté serveur, le client,
en réponse à cette réponse, devra envoyer sa requête,
y compris un champ d'en-tête spécifique dans le message de demande de l'autorisation de type.
Et ce champ d'en-tête d'autorisation contiendra des informations là-dedans.
Pour une authentification de base, cette information serait sous la forme de,
comme le premier mot ici, sera Basic.
Puis suivi d'un espace ici, et suivi d'une chaîne codée en Base64 ici.
Cette chaîne codée Base64 code le nom d'utilisateur et le
mot de passe dans un format particulier, puis l'inclut dans l'en-tête.
Maintenant, vous dites, si vous envoyez un message de requête comme celui-ci,
y compris ceci, dans l'en-tête, alors n'importe qui au milieu.
Donc, si vous savez quelque chose sur la sécurité et
comment les attaques de l'homme au milieu peuvent être lancées, alors évidemment,
cela peut être récupéré par un intrus entre les deux,
et ensuite peut être utilisé pour simuler le vrai client.
Encore une fois, nous n'abordons pas cette question pour le moment.
Quand je parle de HTTPS dans le module suivant,
je reviendrai pour aborder ce problème un peu plus en détail.
Mais pour le moment, les informations dans l'en-tête seront envoyées
sans être cryptées dans l'en-tête en ce moment.
Maintenant, une autre raison pour laquelle je fais cela est que, afin que nous puissions réellement regarder
l'en-tête directement et ensuite voir cette information dans l'en-tête lui-même.
Ainsi, lorsque le client envoie cette requête, le serveur extraire
les informations de cet en-tête d'autorisation dans l'en-tête de requête.
Ensuite, utilisez ces informations afin de vérifier s'il s'agit
d'une demande de client autorisée ou non.
Maintenant, bien sûr, votre prochaine question serait,
que contient exactement cet en-tête d'autorisation ?
L' en-tête d'autorisation lui-même est construit comme suit.
Si vous avez un nom d'utilisateur et un mot de passe, ce sont les deux
informations que vous utiliserez pour authentifier un client.
Ainsi, le nom d'utilisateur et le mot de passe seront concaténés en une seule chaîne
en disant nom d'utilisateur et deux points, et le mot de passe lui-même.
Ainsi, la chaîne de nom d'utilisateur, les deux-points et le
mot de passe seront concaténés ensemble dans une chaîne entière ici.
Cette chaîne résultante que nous obtenons ici est celle, encodée en utilisant Base64 encoder.
Si vous savez comment l'encodage est fait les bases pour l'encodage,
convertissez-le en un en-tête ASCII comme indiqué dans cet exemple ici,
donc ce n'est rien d'autre qu'une chaîne d'en-têtes ASCII.
Maintenant, si vous ne savez pas grand-chose sur l'encodage rigide de base, ne vous inquiétez pas,
cela n'affecte pas votre compréhension de ce qui se passe ici de toute façon.
Donc, cette Basic64 chaînes encodées, donc
cette information particulière est encodée dans une chaîne comme celle-ci,
puis enfermée dans l'en-tête de requête allant du client au serveur.
L' en-tête de requête lui-même est de l'autorisation de type,
puis suivi de la valeur réelle ici, qui dit,
Basic, et un espace ici, et de la chaîne codée Base64 ici.
Donc, lorsque cela est reçu par notre serveur, le serveur va extraire ces informations,
puis à partir d'ici, il va extraire le nom d'utilisateur et le mot de passe,
puis vérifier si cela correspond à un utilisateur autorisé ou non du côté serveur.
Pour vous aider à mieux comprendre comment nous organisons réellement l'application express
et comment l'authentification elle-même est effectuée, comme nous l'avons appris précédemment, les
applications express elles-mêmes sont organisées dans un ensemble de middleware.
Et la façon dont l'application express fonctionne est que le middleware est
appliqué à la requête et au message de réponse
dans l'ordre dans lequel il est déclaré dans mon application express.
Donc, si vous avez un express.use et que
vous avez le premier qui dit un serveur statique, alors après cela,
vous avez un autre middleware, puis après cela, vous avez un autre middleware.
La séquence dans laquelle ils sont déclarés dans le fichier app.js express servers,
par exemple, est la séquence exacte dans laquelle le middleware sera appliqué.
Donc, une requête entrante du côté serveur comme vous le rappelez dans votre
application express, la requête entrante est traitée comme un objet de requête.
L' objet de réponse est ce que le serveur express construit,
puis le suivant est vous permet de passer au middleware suivant
que vous allez appliquer, et ainsi de suite.
Donc, une requête entrante comme celle-ci, quand il arrive, le premier middleware est appliqué.
Et puis une fois que ce middleware a transformé à la fois
la requête et la réponse, il passe au middleware suivant, qui lui est ensuite appliqué.
Donc, par exemple, nous avons vu que nous avons appliqué Morgan d'abord,
puis nous avons appliqué body parser au middleware.
Ils doivent donc avoir déjà transformé la requête et les objets de réponse.
Et puis après cela, nous pouvons inclure un middleware d'authentification en place là-bas.
Le middleware d'authentification va authentifier la requête.
Maintenant, donc si vous utilisez l'authentification de base, faites votre demande
doit contenir dans l'en-tête l'en-tête d'autorisation en place là.
Ainsi, l'en-tête d'autorisation sera extrait par le middleware d'authentification
, puis vérifié pour voir si l'utilisateur est autorisé.
Et si le middleware d'authentification détecte que vous êtes un utilisateur autorisé,
vous serez autorisé à passer à l'ensemble suivant de
middleware qui suit l'étape d'authentification.
Et vos enregistrements seront traités par le middleware suivant.
Mais d'autre part,
si votre middleware d'authentification décide que vous n'êtes pas un utilisateur autorisé,
alors le middleware d'authentification vous emmènera le long d'un chemin différent.
Puis générez une erreur, puis renvoyez
une réponse d'erreur appropriée à ce côté client et
sera redirigé vers le gestionnaire d'erreurs.
Donc, cette redirection vers le gestionnaire d'erreurs sera effectuée en appelant Next
avec l'erreur comme paramètre de ce Next ici.
Donc, le suivant est exactement ce Suivant que nous voyons dans la ressource de requête Suivant ici.
Et donc, cela vous mènera jusqu'au gestionnaire d'erreurs,
qui gérera l'erreur, puis renvoyera le message d'erreur vers le côté client,
indiquant l'échec de l'authentification.
C' est ainsi que
fonctionne votre autorisation de base typique, ou authentification de base dans votre application côté serveur.
Après avoir compris cela, passons à l'exercice où nous
allons implémenter l'authentification de base dans notre application et
voir comment elle authentifie les utilisateurs.
[ MUSIQUE]