1
00:00:00,000 --> 00:00:04,649
[MUSIQUE]

2
00:00:04,649 --> 00:00:08,820
Dans la leçon précédente, nous avons appris sur l'authentification de base.

3
00:00:08,820 --> 00:00:14,398
Nous avons vu que dans l'authentification de base, le client devra explicitement continuer à

4
00:00:14,398 --> 00:00:19,720
ajouter dans le champ d'autorisation contenant le nom d'utilisateur et le

5
00:00:19,720 --> 00:00:24,100
mot de passe pour chaque requête que le client envoie au côté serveur.

6
00:00:24,100 --> 00:00:27,750
Maintenant, c'est parfaitement bien pour une authentification simple.

7
00:00:27,750 --> 00:00:33,520
Les cookies sont encore un autre mécanisme qui est fourni qui permet

8
00:00:33,520 --> 00:00:38,700
à votre serveur de pouvoir s'attendre à ce

9
00:00:38,700 --> 00:00:43,370
que le client stocke certaines informations côté client et inclut explicitement ces informations dans chaque requête sortante.

10
00:00:43,370 --> 00:00:47,360
Donc, au lieu d'inclure votre nom d'utilisateur et votre mot de

11
00:00:47,360 --> 00:00:53,710
passe codés en base 64 comme nous l'avons fait dans l'authentification de base, en utilisant

12
00:00:53,710 --> 00:00:58,130
des cookies, votre serveur peut configurer une information explicite du côté client

13
00:00:58,130 --> 00:01:02,520
qui sera ensuite incluse dans chaque demande sortante du côté client.

14
00:01:03,750 --> 00:01:08,740
Maintenant, si votre serveur veut suivre les informations sur votre

15
00:01:08,740 --> 00:01:15,180
client, le serveur peut configurer explicitement un mécanisme de suivi de session.

16
00:01:15,180 --> 00:01:20,720
Maintenant, les cookies sont petits et ne peuvent pas stocker beaucoup d'informations là-dedans,

17
00:01:20,720 --> 00:01:25,230
et cela, bien sûr, ne peut pas être inclus dans la demande sortante.

18
00:01:25,230 --> 00:01:28,010
Les cookies peuvent inclure des informations de base

19
00:01:28,010 --> 00:01:31,850
dans l'en-tête de la demande sortante du client.

20
00:01:31,850 --> 00:01:37,010
Maintenant, si nous voulons que beaucoup plus d'informations soient suivies sur un client

21
00:01:37,010 --> 00:01:42,420
côté serveur, alors les sessions express nous permettent de le faire.

22
00:01:42,420 --> 00:01:45,140
Étudions plus sur les cookies et les

23
00:01:45,140 --> 00:01:49,260
sessions Express un peu plus en détail dans cette leçon et

24
00:01:49,260 --> 00:01:54,380
explorons-les plus loin dans les exercices qui suivent cette conférence.

25
00:01:56,640 --> 00:01:59,340
Alors, que sont les cookies HTTP ?

26
00:01:59,340 --> 00:02:04,070
Les cookies HTTP, comme je l'ai mentionné, sont un petit morceau de données qui est envoyé

27
00:02:04,070 --> 00:02:07,610
à partir d'un serveur Web et est stocké du côté client.

28
00:02:07,610 --> 00:02:12,030
Maintenant, presque tous les navigateurs ont la possibilité de prendre en charge

29
00:02:12,030 --> 00:02:16,850
le stockage des cookies côté client, et de les inclure automatiquement

30
00:02:16,850 --> 00:02:21,590
dans la demande lorsque la demande est envoyée à un serveur spécifique.

31
00:02:21,590 --> 00:02:27,127
Ainsi, chaque requête suivante du

32
00:02:27,127 --> 00:02:32,047
côté client inclura un nouvel en-tête là-dedans

33
00:02:32,047 --> 00:02:37,141
avec le cookie dans l'en-tête de la requête.

34
00:02:37,141 --> 00:02:41,668
Maintenant, évidemment, si vous avez vu la presse populaire

35
00:02:41,668 --> 00:02:45,450
y avoir eu une mauvaise réputation, ce n'est, bien sûr, pas tout à fait injustifié.

36
00:02:45,450 --> 00:02:52,880
Mais il est soufflé loin de proportion que ce qui est vraiment la vérité.

37
00:02:52,880 --> 00:02:57,760
Alors prenez tout ce que vous lisez dans la presse populaire sur les cookies et

38
00:02:57,760 --> 00:03:00,570
leur mauvaise réputation avec un grain de sel.

39
00:03:00,570 --> 00:03:05,040
Les cookies sont très utiles pour faire beaucoup de choses intéressantes.

40
00:03:05,040 --> 00:03:09,880
Et nous pouvons nous assurer que les cookies peuvent avoir une

41
00:03:09,880 --> 00:03:15,070
intégrité suffisante pour qu'ils ne puissent pas être manipulés par quiconque entre les deux.

42
00:03:15,070 --> 00:03:21,640
Maintenant, comment fonctionne cette inclusion de paramètre de cookie dans la requête sortante ?

43
00:03:21,640 --> 00:03:25,060
Lorsqu' un client envoie une requête au site serveur,

44
00:03:25,060 --> 00:03:27,870
si le client est authentifié sur le site serveur.

45
00:03:27,870 --> 00:03:31,040
Par exemple, en utilisant l'authentification de base

46
00:03:31,040 --> 00:03:34,950
, le serveur peut en retour, configurer un cookie.

47
00:03:34,950 --> 00:03:39,120
Maintenant, pour configurer un cookie sur le site du client, le serveur inclura dans

48
00:03:39,120 --> 00:03:44,090
le message de réponse un en-tête avec l'en-tête du cookie envoyé et

49
00:03:44,090 --> 00:03:46,300
le cookie réel dans l'en-tête.

50
00:03:46,300 --> 00:03:50,460
Maintenant, lorsque le client reçoit le message de réponse

51
00:03:50,460 --> 00:03:54,500
du serveur contenant l'en-tête Set-Cookie, il va configurer le cookie côté client.

52
00:03:54,500 --> 00:03:59,455
De telle sorte que chaque requête suivante allant du côté client

53
00:03:59,455 --> 00:04:03,602
inclura explicitement un champ d'en-tête appelé comme cookie et l'

54
00:04:03,602 --> 00:04:06,846
en-tête réel qui contient comme valeur,

55
00:04:06,846 --> 00:04:13,200
les informations de cookie qui ont été envoyées par le serveur dans le message de réponse.

56
00:04:13,200 --> 00:04:17,880
Ainsi, chaque message de demande suivant portera ce cookie dans l'en-tête.

57
00:04:17,880 --> 00:04:22,470
Ainsi, lorsque le serveur reçoit ce message de requête, il est capable d'examiner

58
00:04:22,470 --> 00:04:28,490
le cookie et de supposer d'où provient cette requête.

59
00:04:28,490 --> 00:04:33,612
Ainsi, il est capable de reconnaître le client en regardant les informations sur les cookies.

60
00:04:33,612 --> 00:04:38,543
C' est donc là que les cookies s'avèrent très utiles

61
00:04:38,543 --> 00:04:44,019
pour envoyer des informations d'autorisation.

62
00:04:44,019 --> 00:04:48,050
Donc, en servant incluant le nom d'utilisateur et le mot de passe comme partie de l'

63
00:04:48,050 --> 00:04:51,220
en-tête d'authentification de base dans chaque demande en cours.

64
00:04:51,220 --> 00:04:55,120
La première fois que vous vous authentifiez, vous envoyez votre nom d'utilisateur et votre mot de passe et

65
00:04:55,120 --> 00:04:57,140
le serveur installe le cookie de votre côté.

66
00:04:57,140 --> 00:05:02,070
Par la suite, il vous suffit d'inclure le cookie dans la demande sortante.

67
00:05:02,070 --> 00:05:06,789
Maintenant, les cookies peuvent également avoir une date d'expiration associée à eux.

68
00:05:06,789 --> 00:05:11,641
Ainsi, à ce stade, le cookie sera considéré comme expiré et

69
00:05:11,641 --> 00:05:13,440
ne sera plus valide.

70
00:05:13,440 --> 00:05:16,940
C' est donc une façon de contrôler la durée pour

71
00:05:16,940 --> 00:05:20,340
laquelle une autorisation est valide.

72
00:05:20,340 --> 00:05:24,350
En arrivant à Express lui-même, comment Express prend-il en charge les cookies ?

73
00:05:24,350 --> 00:05:28,980
Maintenant, comme nous le comprenons, Express utilise beaucoup de middleware.

74
00:05:28,980 --> 00:05:34,100
C' est là que l'un des middlewares qui vient en appelé l'analyseur de cookies

75
00:05:34,100 --> 00:05:37,092
arrive à notre application à huit heures.

76
00:05:37,092 --> 00:05:42,580
L' analyseur de cookies permet au serveur de configurer un cookie dans l'en-tête de réponse.

77
00:05:42,580 --> 00:05:48,350
Donc, cela se fait en utilisant res.cookie et le nom et

78
00:05:48,350 --> 00:05:54,160
certaines valeurs et les options comme nous le verrons dans l'exercice plus tard.

79
00:05:54,160 --> 00:06:00,160
Et donc les cookies, lorsqu'ils sont envoyés du côté client, inclus dans ce

80
00:06:00,160 --> 00:06:05,980
message de demande, sont analysés du côté serveur Express, en utilisant l'analyseur de cookies.

81
00:06:05,980 --> 00:06:08,383
Le middleware cookie-parser,

82
00:06:08,383 --> 00:06:13,400
qui, une fois installé, vous permettra d'analyser les cookies entrants.

83
00:06:13,400 --> 00:06:17,280
Et puis ces cookies entrants seront ajoutés dans

84
00:06:17,280 --> 00:06:22,260
la demande en tant qu'en-tête et peuvent être examinés côté serveur.

85
00:06:23,340 --> 00:06:26,580
Maintenant, afin de protéger l'authenticité du cookie,

86
00:06:26,580 --> 00:06:30,070
les cookies eux-mêmes peuvent être signés par le serveur.

87
00:06:30,070 --> 00:06:35,120
Maintenant, lorsque le serveur signe un cookie, le serveur utilise une clé secrète,

88
00:06:35,120 --> 00:06:38,070
qui n'est connue que du côté serveur.

89
00:06:38,070 --> 00:06:42,510
Maintenant, si vous savez quelque chose sur la sécurité informatique, la cryptographie et le

90
00:06:42,510 --> 00:06:47,210
cryptage, alors vous comprenez ce que

91
00:06:47,210 --> 00:06:49,290
signifient la signature, les clés secrètes et les clés publiques et toutes ces choses.

92
00:06:49,290 --> 00:06:53,990
Si vous ne le faites pas, il suffit de dire qu'une clé secrète est

93
00:06:53,990 --> 00:06:59,260
une chaîne spécifique que seul le serveur connaît et que personne d'autre ne sait.

94
00:06:59,260 --> 00:07:05,505
Ainsi, lorsqu'un serveur crypte un cookie, il utilise une clé secrète comme signature et

95
00:07:05,505 --> 00:07:11,081
crée ce qu'on appelle un code d'authentification de message de hachage clé.

96
00:07:11,081 --> 00:07:16,450
Et inclut ceci dans ce cookie qui est envoyé du serveur vers le côté client.

97
00:07:16,450 --> 00:07:21,210
Ce HMAC qui est créé côté serveur ne peut être fait

98
00:07:21,210 --> 00:07:24,540
que par ce serveur spécifique connaissant cette clé secrète.

99
00:07:24,540 --> 00:07:27,950
Maintenant, puisque le serveur est une ressource protégée,

100
00:07:27,950 --> 00:07:33,670
seul le serveur connaîtra la clé secrète et il est donc très facile de vérifier

101
00:07:33,670 --> 00:07:38,320
quand un cookie signé est envoyé du côté client au côté serveur.

102
00:07:38,320 --> 00:07:42,040
Ainsi, lorsque le cookie signé est envoyé du côté client au côté serveur,

103
00:07:42,040 --> 00:07:44,540
le cookie sera configuré du côté client,

104
00:07:44,540 --> 00:07:50,310
puis toutes les demandes suivantes incluront ce cookie signé du côté client.

105
00:07:50,310 --> 00:07:54,290
Maintenant, le middleware de l'analyseur de cookies que nous avons mis en place avec notre serveur Express

106
00:07:54,290 --> 00:07:56,630
prend déjà en charge les cookies signés.

107
00:07:56,630 --> 00:08:02,480
Maintenant, pour cela, dans l'analyseur de cookies, vous fournirez également la clé secrète comme

108
00:08:02,480 --> 00:08:07,120
paramètre pour l'analyseur de cookies lorsque vous configurez le middleware de l'analyseur de cookies.

109
00:08:07,120 --> 00:08:11,970
Ainsi, tous les cookies seront signés de manière appropriée, puis envoyés.

110
00:08:11,970 --> 00:08:17,240
Et lorsque le cookie est analysé côté serveur dans le

111
00:08:17,240 --> 00:08:22,660
message de demande entrante, il sera ajouté dans le message de demande en tant que req.signedCookies.

112
00:08:22,660 --> 00:08:27,980
Et puis vous pouvez avoir un champ spécifique que vous pouvez enregistrer dans le cookie signé.

113
00:08:27,980 --> 00:08:30,890
Les cookies sont un moyen très utile pour

114
00:08:30,890 --> 00:08:36,380
que votre client puisse envoyer des informations par lesquelles votre serveur reconnaît le client.

115
00:08:36,380 --> 00:08:38,490
Mais bien sûr, les cookies ont des limites.

116
00:08:38,490 --> 00:08:42,370
Ils ont une taille fixe, de sorte qu'ils ne peuvent pas encoder beaucoup d'

117
00:08:42,370 --> 00:08:47,090
informations sur le client que leur serveur peut récupérer à partir du cookie.

118
00:08:47,090 --> 00:08:50,710
Le cookie est utilisé pour rappeler au serveur

119
00:08:50,710 --> 00:08:53,750
quel client envoie la requête.

120
00:08:53,750 --> 00:08:58,311
Maintenant, si vous voulez avoir un mécanisme plus élaboré pour suivre les informations sur

121
00:08:58,311 --> 00:09:02,889
un client, alors du côté serveur, vous pouvez configurer ce que l'on appelle des sessions.

122
00:09:02,889 --> 00:09:09,180
Désormais, les sessions sont un mécanisme générique disponible avec tous les serveurs.

123
00:09:09,180 --> 00:09:11,850
En particulier, nous examinerons Express lui-même et

124
00:09:11,850 --> 00:09:17,140
comment Express prend en charge la gestion des sessions côté serveur.

125
00:09:17,140 --> 00:09:22,930
La façon dont cela fonctionne est que la session utilisateur est configurée côté serveur.

126
00:09:22,930 --> 00:09:27,430
Donc, cette session elle-même est une combinaison d'un cookie et

127
00:09:27,430 --> 00:09:32,270
d'un ID de session, et le côté serveur suit les informations

128
00:09:32,270 --> 00:09:37,250
associées à cet ID de session, ou indexées par cet ID de session.

129
00:09:37,250 --> 00:09:40,500
Les informations de session elles-mêmes peuvent avoir n'importe quelle

130
00:09:40,500 --> 00:09:45,380
quantité d'informations faisant l'objet d'un suivi côté serveur et indexées par ce cookie.

131
00:09:45,380 --> 00:09:50,910
Donc, quand un client envoie une requête sur le serveur, puis à partir du cookie

132
00:09:50,910 --> 00:09:56,130
l'ID de session est récupéré et qui est utilisé comme un index dans le côté serveur.

133
00:09:56,130 --> 00:09:56,964
Par exemple,

134
00:09:56,964 --> 00:10:01,548
si vous utilisez une base de données côté serveur, cet index sera l'index principal de

135
00:10:01,548 --> 00:10:05,456
cette base de données côté serveur particulière qui suit les sessions. Par

136
00:10:05,456 --> 00:10:10,486
conséquent, des informations supplémentaires sur cette session peuvent être récupérées et

137
00:10:10,486 --> 00:10:13,761
utilisées par votre serveur afin de prendre des décisions sur la façon dont

138
00:10:13,761 --> 00:10:17,380
il traite la demande du client entrant.

139
00:10:17,380 --> 00:10:23,900
Désormais, par défaut, les sessions sont stockées en mémoire sur le site du serveur.

140
00:10:23,900 --> 00:10:28,870
Maintenant, évidemment, cela signifie que si votre serveur est redémarré, votre mémoire

141
00:10:28,870 --> 00:10:33,260
sera effacée et donc toutes les informations de session disparaîtront complètement.

142
00:10:33,260 --> 00:10:37,350
Donc, à la place, de nombreux serveurs

143
00:10:37,350 --> 00:10:42,010
utiliseront une forme de stockage permanent où les informations de session sont suivies.

144
00:10:42,010 --> 00:10:45,360
Le stockage permanent côté serveur pourrait soit être fait

145
00:10:45,360 --> 00:10:47,500
via une sorte de stockage de fichiers.

146
00:10:47,500 --> 00:10:53,460
Ou même tirer parti du fait que vous avez déjà une base de données côté serveur et

147
00:10:53,460 --> 00:10:56,170
que stocker les informations de session côté serveur.

148
00:10:56,170 --> 00:10:59,590
Par exemple, dans votre MongoDB lui-même.

149
00:10:59,590 --> 00:11:05,620
Maintenant, dans l'exercice qui suit, nous allons examiner l'utilisation d'un stockage de fichiers pour

150
00:11:05,620 --> 00:11:10,000
le suivi des informations de session côté serveur.

151
00:11:10,000 --> 00:11:14,450
Un autre aspect auquel vous devez prêter attention est le fait que si vous avez

152
00:11:14,450 --> 00:11:19,540
une implémentation de serveur distribué dans laquelle plusieurs

153
00:11:19,540 --> 00:11:24,530
serveurs agissent comme le serveur pour la maintenance de la requête.

154
00:11:24,530 --> 00:11:28,310
Ensuite, le serveur du distributeur doit pouvoir accéder aux informations de session.

155
00:11:29,460 --> 00:11:32,470
N' importe lequel de ces serveurs doit pouvoir accéder aux informations de session.

156
00:11:32,470 --> 00:11:36,480
Vous aurez donc besoin d'un outil de sessions de distribution côté serveur,

157
00:11:36,480 --> 00:11:40,780
pour vous permettre de prendre en charge plusieurs serveurs répliqués.

158
00:11:40,780 --> 00:11:45,450
Cela est particulièrement utile lorsque nous essayons d'assurer la fiabilité

159
00:11:45,450 --> 00:11:46,870
du fonctionnement du serveur.

160
00:11:47,960 --> 00:11:52,630
Maintenant encore une fois, nous n'aurons pas trop de détails sur ceux de ce

161
00:11:52,630 --> 00:11:58,190
cours particulier, nous compterons sur la compréhension de la façon dont fonctionnent les sessions Express.

162
00:11:59,710 --> 00:12:02,080
Venir spécifiquement à Express et

163
00:12:02,080 --> 00:12:06,080
comment la gestion des sessions est prise en charge dans Express.

164
00:12:06,080 --> 00:12:10,240
Express utilise le middleware express-session qui prend en charge

165
00:12:10,240 --> 00:12:14,760
l'utilisation de sessions dans un serveur Express.

166
00:12:14,760 --> 00:12:18,110
Maintenant, vous installez le middleware express-sessions.

167
00:12:18,110 --> 00:12:21,140
Et dans l'exercice, je vais utiliser la boutique de fichiers

168
00:12:21,140 --> 00:12:24,470
comme un moyen de stocker de façon permanente les informations de session.

169
00:12:24,470 --> 00:12:30,440
Et donc, nous allons également inclure le module de nœud de stockage de fichiers de session qui

170
00:12:30,440 --> 00:12:37,305
nous permet d'utiliser les fichiers côté serveur pour suivre les informations de session.

171
00:12:37,305 --> 00:12:41,120
Nous verrons les détails dans l'exercice qui suit.

172
00:12:41,120 --> 00:12:46,247
Et puis une fois que nous le faisons, votre session elle-même sera configurée avec le nouveau

173
00:12:46,247 --> 00:12:51,690
serveur express en déclarant le middleware ici comme session qui prend

174
00:12:51,690 --> 00:12:57,390
un certain ensemble d'options comme paramètre ici.

175
00:12:57,390 --> 00:13:02,200
Les options incluent le nom de la session, donc nous donnerons l'identifiant de session pour

176
00:13:02,200 --> 00:13:03,500
la session particulière.

177
00:13:03,500 --> 00:13:07,500
Et puis vous fournirez également le secret, une clé secrète qui est utilisée pour

178
00:13:07,500 --> 00:13:12,460
coder le cookie signé qui sera envoyé côté client.

179
00:13:12,460 --> 00:13:17,960
Et puis aussi des informations supplémentaires, y compris saveUnInitialized, qui

180
00:13:19,190 --> 00:13:24,625
sera un indicateur qui est utilisé et aussi un indicateur de resave qui est utilisé.

181
00:13:24,625 --> 00:13:28,760
Nous examinerons certains détails de ces options dans la diapositive suivante.

182
00:13:28,760 --> 00:13:31,390
Donc, toutes ces options sont spécifiées ici.

183
00:13:31,390 --> 00:13:36,945
Et si vous êtes FileStore comme le stockage permanent pour vos sessions,

184
00:13:36,945 --> 00:13:42,130
alors nous le déclarerons également dans les options de session là-bas.

185
00:13:42,130 --> 00:13:47,450
C' est ainsi que nous mettrions en place une session côté serveur express

186
00:13:47,450 --> 00:13:49,510
en utilisant le Middleware de session express.

187
00:13:49,510 --> 00:13:55,540
Et le middleware de session express-, lorsque le client envoie ces informations,

188
00:13:55,540 --> 00:13:58,980
cela sera analysé côté serveur et

189
00:13:58,980 --> 00:14:04,640
cela entraînera l'ajout d'une propriété appelée session à l'objet requête.

190
00:14:04,640 --> 00:14:09,460
Donc, ces informations de session seront accessibles dans l'

191
00:14:09,460 --> 00:14:11,505
objet requête en tant que req.session.

192
00:14:11,505 --> 00:14:16,221
Ainsi, req.session portera des informations supplémentaires sur cette session particulière

193
00:14:16,221 --> 00:14:18,325
pour ce client particulier.

194
00:14:18,325 --> 00:14:22,979
Maintenant, une fois cette session, la requête entrante est analysée par le middleware de session,

195
00:14:22,979 --> 00:14:28,957
la propriété req.session sera ajoutée à l'

196
00:14:28,957 --> 00:14:33,447
objet de message de requête entrant utilisé par express.

197
00:14:33,447 --> 00:14:40,097
Donc, après l'analyse de la session, la propriété de session directe sera disponible et

198
00:14:40,097 --> 00:14:46,165
nous pouvons l'examiner aussi pour vérifier quel client a envoyé cette demande.

199
00:14:46,165 --> 00:14:50,900
Quand ils configurent leur objet de session sur le site du serveur,

200
00:14:50,900 --> 00:14:54,760
comme nous l'avons vu, nous pouvons configurer diverses options pour ce site de serveur.

201
00:14:54,760 --> 00:14:59,790
Le cookie, les options du cookie d'ID de session et la valeur par défaut

202
00:14:59,790 --> 00:15:04,275
du cookie seront comme indiqué ici, qui est le chemin : '/',

203
00:15:04,275 --> 00:15:07,700
HttpOnly : true, secure : false, MaxAge : null.

204
00:15:07,700 --> 00:15:13,450
Donc, ce sera la valeur par défaut du cookie qui sera stocké sur le paquet

205
00:15:13,450 --> 00:15:17,680
et envoyé sur le côté du client en tant que cookie signé.

206
00:15:17,680 --> 00:15:23,306
Et cela serait inclus dans chaque demande entrante du site du client.

207
00:15:23,306 --> 00:15:28,080
Ensuite, le genid est la fonction qui génère l'ID de session.

208
00:15:28,080 --> 00:15:33,830
La valeur par défaut consiste à utiliser l'UUID du serveur lui-même comme ID général.

209
00:15:33,830 --> 00:15:38,720
Ensuite, l'indicateur de resave, s'il est vrai, force une session à être sauvegardée

210
00:15:38,720 --> 00:15:41,470
dans le magasin même si elle n'est pas modifiée par la requête.

211
00:15:41,470 --> 00:15:44,230
Parfois, la requête entrante peut

212
00:15:45,580 --> 00:15:50,200
contenir un besoin de modifier les informations de session côté serveur.

213
00:15:50,200 --> 00:15:54,300
Par conséquent, si les informations de session sont modifiées, elles devront être persistantes.

214
00:15:54,300 --> 00:15:56,290
Si ce n'est pas le cas, alors vous n'avez pas besoin de le persister.

215
00:15:56,290 --> 00:16:00,454
Mais si vous définissez l'indicateur de resave sur true, même si les informations de session sur

216
00:16:00,454 --> 00:16:06,030
le serveur ne sont pas modifiées par la demande du client entrant, il sera toujours régénéré.

217
00:16:06,030 --> 00:16:09,980
L' indicateur suivant que nous avons examiné était SaveUnInitialized.

218
00:16:09,980 --> 00:16:14,620
Si cela est vrai, il va créer une session nouvellement créée sans aucune modification

219
00:16:14,620 --> 00:16:16,540
à enregistrer dans le magasin de sessions.

220
00:16:16,540 --> 00:16:21,164
Maintenant, nous allons définir ceci sur false par défaut, ce qui signifie que nous allons seulement

221
00:16:21,164 --> 00:16:25,008
suivre les sessions qui sont autorisées sur le serveur.

222
00:16:25,008 --> 00:16:30,955
Maintenant, le secret, comme nous le voyons, est la clé secrète qui est utilisée pour signer le cookie,

223
00:16:30,955 --> 00:16:36,310
et le magasin lui-même spécifie l'instance de magasin de session qui est utilisée.

224
00:16:36,310 --> 00:16:39,810
La valeur par défaut est d'utiliser le magasin de mémoire.

225
00:16:39,810 --> 00:16:42,950
Vous pouvez spécifier le magasin de fichiers ou le magasin Mongo pour

226
00:16:42,950 --> 00:16:46,000
stocker ces informations de session, etc.

227
00:16:46,000 --> 00:16:51,590
Donc, une fois que vous spécifiez ces informations pour votre intergiciel

228
00:16:51,590 --> 00:16:57,350
de session express, la session sera correctement configurée et sera donc suivie du côté serveur.

229
00:16:57,350 --> 00:17:02,430
Chaque requête client sera ensuite mappée aux informations de session

230
00:17:02,430 --> 00:17:08,260
côté serveur lorsque la requête client est analysée par le middleware de session express.

231
00:17:08,260 --> 00:17:12,960
Et le req.session sera ajouté dans l'objet requête.

232
00:17:14,150 --> 00:17:19,010
Avec cette compréhension des cookies et des sessions express, passons

233
00:17:19,010 --> 00:17:24,050
à l'exercice où nous allons examiner comment nous allons utiliser les cookies en premier.

234
00:17:24,050 --> 00:17:29,360
Ensuite, nous allons voir comment nous allons utiliser les sessions Express

235
00:17:29,360 --> 00:17:35,121
dans notre application API REST Express sur laquelle nous avons travaillé jusqu'à présent.

236
00:17:35,121 --> 00:17:40,109
[ MUSIQUE]