1
00:00:00,000 --> 00:00:04,470
[MUSIC]

2
00:00:04,470 --> 00:00:10,326
Le serveur API REST Express que nous avons implémenté dans le

3
00:00:10,326 --> 00:00:17,750
module précédent permet à tout utilisateur d'effectuer l'une des opérations GET, POST ou DELETE. Il

4
00:00:17,750 --> 00:00:21,360
n'y a aucun contrôle sur qui peut effectuer cette opération.

5
00:00:21,360 --> 00:00:22,350
Donc, ce qui signifie que,

6
00:00:22,350 --> 00:00:27,180
si vous exécutez un serveur comme celui-ci, alors n'importe qui peut entrer dans votre serveur et

7
00:00:27,180 --> 00:00:33,420
commencer à manipuler les informations qui sont présentes dans votre base de données.

8
00:00:33,420 --> 00:00:36,578
C' est évidemment une situation dangereuse.

9
00:00:36,578 --> 00:00:40,380
La façon dont ce serveur doit être implémenté est que,

10
00:00:40,380 --> 00:00:44,330
vous devez avoir une sorte de restriction sur les

11
00:00:44,330 --> 00:00:48,660
types d'utilisateurs qui seront autorisés à effectuer quels types d'opérations.

12
00:00:48,660 --> 00:00:51,090
Donc peut-être, vous autoriseriez et

13
00:00:51,090 --> 00:00:54,650
un utilisateur autorisé uniquement à effectuer des opérations GET.

14
00:00:54,650 --> 00:01:00,040
Par exemple, si vous voulez qu'un invité puisse voir des

15
00:01:00,040 --> 00:01:04,860
informations sur les plats de votre restaurant ou le menu de votre restaurant,

16
00:01:04,860 --> 00:01:07,250
etc., c'est parfaitement acceptable.

17
00:01:07,250 --> 00:01:11,699
Mais, vous pouvez autoriser seulement un administrateur à entrer et

18
00:01:11,699 --> 00:01:17,780
modifier les informations sur le plat ou à supprimer un plat du menu.

19
00:01:17,780 --> 00:01:23,448
Et aussi mettre à jour un plat existant dans le menu,

20
00:01:23,448 --> 00:01:29,062
ou une promotion, ou les informations sur les leaders dans votre serveur.

21
00:01:29,062 --> 00:01:34,810
Maintenant, vous pouvez également avoir un autre groupe d'utilisateurs qui seront des utilisateurs enregistrés

22
00:01:34,810 --> 00:01:39,980
qui peuvent être autorisés à enregistrer certains de leurs plats comme leurs plats préférés,

23
00:01:39,980 --> 00:01:44,290
et seulement ils seraient en mesure de manipuler la liste de leurs plats préférés.

24
00:01:44,290 --> 00:01:47,850
C' est donc un autre niveau d'autorisation ou

25
00:01:47,850 --> 00:01:49,940
d'authentification que vous devez effectuer.

26
00:01:49,940 --> 00:01:53,400
Ainsi, vous avez différents niveaux d'utilisateurs, et

27
00:01:53,400 --> 00:01:57,820
aussi, selon le type d'opérations qu'ils seraient autorisés à effectuer.

28
00:01:57,820 --> 00:02:01,880
Donc, tout cela signifie que vous avez besoin d'une sorte de sécurité pour être

29
00:02:01,880 --> 00:02:03,840
intégré dans votre serveur.

30
00:02:03,840 --> 00:02:07,970
Nous allons examiner comment nous pouvons authentifier les utilisateurs,

31
00:02:07,970 --> 00:02:13,110
puis décider quel type d'utilisateur est ce client.

32
00:02:13,110 --> 00:02:15,410
Et puis en fonction du type de l'utilisateur,

33
00:02:15,410 --> 00:02:19,360
vous pouvez autoriser l'utilisateur à effectuer certains types d'opérations.

34
00:02:19,360 --> 00:02:24,630
Nous allons commencer par la compréhension de base de ceci, ce que nous appelons

35
00:02:24,630 --> 00:02:30,860
l'authentification de base dans un côté serveur pour

36
00:02:30,860 --> 00:02:36,940
un client, puis, nous allons construire sur cela tout au long de ce module.

37
00:02:36,940 --> 00:02:42,030
Et puis à la fin de ce module, nous finirons avec un mécanisme

38
00:02:42,030 --> 00:02:46,170
, permettant ainsi aux utilisateurs de s'enregistrer eux-mêmes.

39
00:02:46,170 --> 00:02:50,220
Et, les utilisateurs enregistrés peuvent effectuer certaines opérations

40
00:02:50,220 --> 00:02:53,930
qu'un utilisateur non inscrit ne peut pas, et ainsi de suite.

41
00:02:53,930 --> 00:02:57,320
Nous allons donc imposer différents types de contrôles d'accès pour

42
00:02:57,320 --> 00:03:01,990
diverses opérations côté serveur en fonction du type d'utilisateur.

43
00:03:01,990 --> 00:03:04,930
Donc, cela vous définit la perspective, ou

44
00:03:04,930 --> 00:03:09,830
plutôt l'idée de ce que vous allez rencontrer dans ce module.

45
00:03:09,830 --> 00:03:12,450
Commençons par l'authentification de base,

46
00:03:12,450 --> 00:03:18,450
le mécanisme très basique qui nous permettra d'authentifier les utilisateurs.

47
00:03:19,970 --> 00:03:25,173
L' authentification de base dans HTTP est un mécanisme très simple,

48
00:03:25,173 --> 00:03:28,782
qui demandera à l'utilisateur un nom d'utilisateur et un

49
00:03:28,782 --> 00:03:32,720
mot de passe à soumettre avec une demande.

50
00:03:32,720 --> 00:03:35,180
Et il y a une structure spécifique

51
00:03:35,180 --> 00:03:39,920
sur la façon dont ces informations seront envoyées du client vers le côté serveur.

52
00:03:39,920 --> 00:03:45,060
Donc, c'est une question, l'authentification d'accès de base, que HTTP prend en charge,

53
00:03:45,060 --> 00:03:49,860
est une question qui permettra à un serveur de défier un client, et de demander que

54
00:03:49,860 --> 00:03:53,110
le nom d'utilisateur et le mot de passe soient soumis par le client.

55
00:03:53,110 --> 00:03:57,714
Ainsi, le serveur peut défier le client de s'authentifier en tapant ces

56
00:03:57,714 --> 00:03:59,140
informations.

57
00:03:59,140 --> 00:04:01,880
Le client doit envoyer le nom d'utilisateur et

58
00:04:01,880 --> 00:04:05,440
le mot de passe en réponse au défi du côté serveur.

59
00:04:05,440 --> 00:04:09,870
Ainsi, chaque message de requête provenant d'un client

60
00:04:09,870 --> 00:04:13,870
doit inclure la forme codée du nom d'utilisateur et

61
00:04:13,870 --> 00:04:19,700
du mot de passe dans l'en-tête de requête qui va du client au côté serveur.

62
00:04:19,700 --> 00:04:22,229
Ainsi, lorsque le serveur reçoit la demande,

63
00:04:22,229 --> 00:04:27,009
le serveur extrait ces informations de l'en-tête de requête du client.

64
00:04:27,009 --> 00:04:31,831
Et puis, utilisez cela pour authentifier le client avant

65
00:04:31,831 --> 00:04:37,390
d'autoriser l'accès aux différentes opérations côté serveur.

66
00:04:37,390 --> 00:04:40,850
Alors, comment fonctionne cette authentification ?

67
00:04:40,850 --> 00:04:44,450
Si un client envoie une requête au serveur et que

68
00:04:44,450 --> 00:04:50,150
cette demande client n'inclut pas la formation d'autorisation, alors le serveur

69
00:04:50,150 --> 00:04:55,160
conteste le client, il demande au client de soumettre ces informations.

70
00:04:55,160 --> 00:04:58,100
Le serveur défie le client en incluant

71
00:04:58,100 --> 00:05:01,900
un en-tête dans le message de réponse entrant.

72
00:05:01,900 --> 00:05:06,410
L' en-tête avec le type WW-Authenticate,

73
00:05:06,410 --> 00:05:11,843
puis la deuxième partie où il spécifie le type est où il

74
00:05:11,843 --> 00:05:17,500
spécifiera le type d'authentification que le client doit soumettre.

75
00:05:17,500 --> 00:05:21,990
Et nous allons commencer par la compréhension de l'authentification de base ici.

76
00:05:21,990 --> 00:05:26,400
Et notez également que le message de réponse contiendra un code d'erreur 401,

77
00:05:27,570 --> 00:05:31,270
qui est non autorisé, ce qui signifie non autorisé.

78
00:05:31,270 --> 00:05:35,470
Ainsi, lorsque la réponse revient du côté serveur, le client,

79
00:05:35,470 --> 00:05:41,300
en réponse à cette réponse, devra envoyer sa requête,

80
00:05:41,300 --> 00:05:49,550
y compris un champ d'en-tête spécifique dans le message de demande de l'autorisation de type.

81
00:05:49,550 --> 00:05:55,250
Et ce champ d'en-tête d'autorisation contiendra des informations là-dedans.

82
00:05:55,250 --> 00:06:00,440
Pour une authentification de base, cette information serait sous la forme de,

83
00:06:00,440 --> 00:06:03,900
comme le premier mot ici, sera Basic.

84
00:06:03,900 --> 00:06:11,410
Puis suivi d'un espace ici, et suivi d'une chaîne codée en Base64 ici.

85
00:06:11,410 --> 00:06:15,358
Cette chaîne codée Base64 code le nom d'utilisateur et le

86
00:06:15,358 --> 00:06:21,350
mot de passe dans un format particulier, puis l'inclut dans l'en-tête.

87
00:06:21,350 --> 00:06:25,479
Maintenant, vous dites, si vous envoyez un message de requête comme celui-ci,

88
00:06:25,479 --> 00:06:29,397
y compris ceci, dans l'en-tête, alors n'importe qui au milieu.

89
00:06:29,397 --> 00:06:33,538
Donc, si vous savez quelque chose sur la sécurité et

90
00:06:33,538 --> 00:06:39,927
comment les attaques de l'homme au milieu peuvent être lancées, alors évidemment,

91
00:06:39,927 --> 00:06:44,777
cela peut être récupéré par un intrus entre les deux,

92
00:06:44,777 --> 00:06:49,590
et ensuite peut être utilisé pour simuler le vrai client.

93
00:06:49,590 --> 00:06:52,720
Encore une fois, nous n'abordons pas cette question pour le moment.

94
00:06:52,720 --> 00:06:57,470
Quand je parle de HTTPS dans le module suivant,

95
00:06:57,470 --> 00:07:00,880
je reviendrai pour aborder ce problème un peu plus en détail.

96
00:07:00,880 --> 00:07:06,060
Mais pour le moment, les informations dans l'en-tête seront envoyées

97
00:07:07,880 --> 00:07:11,930
sans être cryptées dans l'en-tête en ce moment.

98
00:07:11,930 --> 00:07:15,460
Maintenant, une autre raison pour laquelle je fais cela est que, afin que nous puissions réellement regarder

99
00:07:15,460 --> 00:07:20,150
l'en-tête directement et ensuite voir cette information dans l'en-tête lui-même.

100
00:07:20,150 --> 00:07:25,401
Ainsi, lorsque le client envoie cette requête, le serveur extraire

101
00:07:25,401 --> 00:07:30,930
les informations de cet en-tête d'autorisation dans l'en-tête de requête.

102
00:07:30,930 --> 00:07:35,078
Ensuite, utilisez ces informations afin de vérifier s'il s'agit

103
00:07:35,078 --> 00:07:37,670
d'une demande de client autorisée ou non.

104
00:07:37,670 --> 00:07:40,412
Maintenant, bien sûr, votre prochaine question serait,

105
00:07:40,412 --> 00:07:44,490
que contient exactement cet en-tête d'autorisation ?

106
00:07:44,490 --> 00:07:48,350
L' en-tête d'autorisation lui-même est construit comme suit.

107
00:07:48,350 --> 00:07:52,180
Si vous avez un nom d'utilisateur et un mot de passe, ce sont les deux

108
00:07:52,180 --> 00:07:55,730
informations que vous utiliserez pour authentifier un client.

109
00:07:55,730 --> 00:08:01,330
Ainsi, le nom d'utilisateur et le mot de passe seront concaténés en une seule chaîne

110
00:08:01,330 --> 00:08:06,910
en disant nom d'utilisateur et deux points, et le mot de passe lui-même.

111
00:08:06,910 --> 00:08:09,860
Ainsi, la chaîne de nom d'utilisateur, les deux-points et le

112
00:08:09,860 --> 00:08:16,210
mot de passe seront concaténés ensemble dans une chaîne entière ici.

113
00:08:16,210 --> 00:08:22,994
Cette chaîne résultante que nous obtenons ici est celle, encodée en utilisant Base64 encoder.

114
00:08:22,994 --> 00:08:27,344
Si vous savez comment l'encodage est fait les bases pour l'encodage,

115
00:08:27,344 --> 00:08:32,390
convertissez-le en un en-tête ASCII comme indiqué dans cet exemple ici,

116
00:08:32,390 --> 00:08:36,195
donc ce n'est rien d'autre qu'une chaîne d'en-têtes ASCII.

117
00:08:36,195 --> 00:08:39,545
Maintenant, si vous ne savez pas grand-chose sur l'encodage rigide de base, ne vous inquiétez pas,

118
00:08:39,545 --> 00:08:44,325
cela n'affecte pas votre compréhension de ce qui se passe ici de toute façon.

119
00:08:44,325 --> 00:08:47,090
Donc, cette Basic64 chaînes encodées, donc

120
00:08:47,090 --> 00:08:51,950
cette information particulière est encodée dans une chaîne comme celle-ci,

121
00:08:51,950 --> 00:08:57,090
puis enfermée dans l'en-tête de requête allant du client au serveur.

122
00:08:57,090 --> 00:09:02,143
L' en-tête de requête lui-même est de l'autorisation de type,

123
00:09:02,143 --> 00:09:07,194
puis suivi de la valeur réelle ici, qui dit,

124
00:09:07,194 --> 00:09:13,774
Basic, et un espace ici, et de la chaîne codée Base64 ici.

125
00:09:13,774 --> 00:09:20,034
Donc, lorsque cela est reçu par notre serveur, le serveur va extraire ces informations,

126
00:09:20,034 --> 00:09:25,059
puis à partir d'ici, il va extraire le nom d'utilisateur et le mot de passe,

127
00:09:25,059 --> 00:09:31,620
puis vérifier si cela correspond à un utilisateur autorisé ou non du côté serveur.

128
00:09:31,620 --> 00:09:36,917
Pour vous aider à mieux comprendre comment nous organisons réellement l'application express

129
00:09:36,917 --> 00:09:42,211
et comment l'authentification elle-même est effectuée, comme nous l'avons appris précédemment, les

130
00:09:42,211 --> 00:09:47,520
applications express elles-mêmes sont organisées dans un ensemble de middleware.

131
00:09:47,520 --> 00:09:51,690
Et la façon dont l'application express fonctionne est que le middleware est

132
00:09:51,690 --> 00:09:55,630
appliqué à la requête et au message de réponse

133
00:09:55,630 --> 00:10:00,940
dans l'ordre dans lequel il est déclaré dans mon application express.

134
00:10:00,940 --> 00:10:05,290
Donc, si vous avez un express.use et que

135
00:10:05,290 --> 00:10:09,740
vous avez le premier qui dit un serveur statique, alors après cela,

136
00:10:09,740 --> 00:10:13,220
vous avez un autre middleware, puis après cela, vous avez un autre middleware.

137
00:10:13,220 --> 00:10:18,560
La séquence dans laquelle ils sont déclarés dans le fichier app.js express servers,

138
00:10:18,560 --> 00:10:23,600
par exemple, est la séquence exacte dans laquelle le middleware sera appliqué.

139
00:10:23,600 --> 00:10:29,124
Donc, une requête entrante du côté serveur comme vous le rappelez dans votre

140
00:10:29,124 --> 00:10:34,690
application express, la requête entrante est traitée comme un objet de requête.

141
00:10:34,690 --> 00:10:39,050
L' objet de réponse est ce que le serveur express construit,

142
00:10:39,050 --> 00:10:43,310
puis le suivant est vous permet de passer au middleware suivant

143
00:10:43,310 --> 00:10:45,910
que vous allez appliquer, et ainsi de suite.

144
00:10:45,910 --> 00:10:52,400
Donc, une requête entrante comme celle-ci, quand il arrive, le premier middleware est appliqué.

145
00:10:52,400 --> 00:10:56,164
Et puis une fois que ce middleware a transformé à la fois

146
00:10:56,164 --> 00:11:00,680
la requête et la réponse, il passe au middleware suivant, qui lui est ensuite appliqué.

147
00:11:00,680 --> 00:11:03,940
Donc, par exemple, nous avons vu que nous avons appliqué Morgan d'abord,

148
00:11:03,940 --> 00:11:06,930
puis nous avons appliqué body parser au middleware.

149
00:11:06,930 --> 00:11:12,930
Ils doivent donc avoir déjà transformé la requête et les objets de réponse.

150
00:11:12,930 --> 00:11:17,440
Et puis après cela, nous pouvons inclure un middleware d'authentification en place là-bas.

151
00:11:17,440 --> 00:11:22,260
Le middleware d'authentification va authentifier la requête.

152
00:11:22,260 --> 00:11:26,950
Maintenant, donc si vous utilisez l'authentification de base, faites votre demande

153
00:11:26,950 --> 00:11:31,970
doit contenir dans l'en-tête l'en-tête d'autorisation en place là.

154
00:11:31,970 --> 00:11:36,260
Ainsi, l'en-tête d'autorisation sera extrait par le middleware d'authentification

155
00:11:36,260 --> 00:11:40,180
, puis vérifié pour voir si l'utilisateur est autorisé.

156
00:11:40,180 --> 00:11:46,099
Et si le middleware d'authentification détecte que vous êtes un utilisateur autorisé,

157
00:11:46,099 --> 00:11:50,515
vous serez autorisé à passer à l'ensemble suivant de

158
00:11:50,515 --> 00:11:54,427
middleware qui suit l'étape d'authentification.

159
00:11:54,427 --> 00:11:58,510
Et vos enregistrements seront traités par le middleware suivant.

160
00:11:58,510 --> 00:11:59,519
Mais d'autre part,

161
00:11:59,519 --> 00:12:04,422
si votre middleware d'authentification décide que vous n'êtes pas un utilisateur autorisé,

162
00:12:04,422 --> 00:12:09,197
alors le middleware d'authentification vous emmènera le long d'un chemin différent.

163
00:12:09,197 --> 00:12:13,975
Puis générez une erreur, puis renvoyez

164
00:12:13,975 --> 00:12:19,368
une réponse d'erreur appropriée à ce côté client et

165
00:12:19,368 --> 00:12:24,010
sera redirigé vers le gestionnaire d'erreurs.

166
00:12:24,010 --> 00:12:28,450
Donc, cette redirection vers le gestionnaire d'erreurs sera effectuée en appelant Next

167
00:12:28,450 --> 00:12:32,490
avec l'erreur comme paramètre de ce Next ici.

168
00:12:32,490 --> 00:12:38,240
Donc, le suivant est exactement ce Suivant que nous voyons dans la ressource de requête Suivant ici.

169
00:12:38,240 --> 00:12:42,760
Et donc, cela vous mènera jusqu'au gestionnaire d'erreurs,

170
00:12:42,760 --> 00:12:48,170
qui gérera l'erreur, puis renvoyera le message d'erreur vers le côté client,

171
00:12:48,170 --> 00:12:51,820
indiquant l'échec de l'authentification.

172
00:12:51,820 --> 00:12:56,720
C' est ainsi que

173
00:12:56,720 --> 00:13:03,435
fonctionne votre autorisation de base typique, ou authentification de base dans votre application côté serveur.

174
00:13:03,435 --> 00:13:08,305
Après avoir compris cela, passons à l'exercice où nous

175
00:13:08,305 --> 00:13:13,176
allons implémenter l'authentification de base dans notre application et

176
00:13:13,176 --> 00:13:15,717
voir comment elle authentifie les utilisateurs.

177
00:13:15,717 --> 00:13:17,952
[ MUSIQUE]