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

2
00:00:04,649 --> 00:00:08,820
Nella lezione precedente, abbiamo appreso l'autenticazione di base.

3
00:00:08,820 --> 00:00:14,398
Abbiamo visto che nell'autenticazione di base il client dovrà continuare esplicitamente ad

4
00:00:14,398 --> 00:00:19,720
aggiungere nel campo di autorizzazione contenente il nome utente e

5
00:00:19,720 --> 00:00:24,100
la password per ogni richiesta che il client invia al lato server.

6
00:00:24,100 --> 00:00:27,750
Ora va perfettamente bene per l'autenticazione semplice.

7
00:00:27,750 --> 00:00:33,520
I cookie sono un altro meccanismo che viene fornito che consente

8
00:00:33,520 --> 00:00:38,700
al server di essere in grado di aspettarsi

9
00:00:38,700 --> 00:00:43,370
che il client memorizzi alcune informazioni sul lato client e includa tali informazioni esplicitamente in ogni richiesta in uscita.

10
00:00:43,370 --> 00:00:47,360
Quindi, invece di includere il tuo nome utente e

11
00:00:47,360 --> 00:00:53,710
la password codificati in base 64 come abbiamo fatto nell'autenticazione

12
00:00:53,710 --> 00:00:58,130
di base, usando i cookie, il tuo server potrebbe impostare un'informazione esplicita sul lato client

13
00:00:58,130 --> 00:01:02,520
che verrà quindi inclusa in ogni richiesta in uscita dal lato client.

14
00:01:03,750 --> 00:01:08,740
Ora espandendo ulteriormente questo, se il tuo server desidera tenere traccia delle informazioni sul tuo

15
00:01:08,740 --> 00:01:15,180
client, allora il server potrebbe impostare esplicitamente un meccanismo di tracciamento della sessione.

16
00:01:15,180 --> 00:01:20,720
Ora, i cookie sono piccoli e non possono memorizzare molte informazioni lì,

17
00:01:20,720 --> 00:01:25,230
e questo ovviamente non può essere incluso nella richiesta in uscita.

18
00:01:25,230 --> 00:01:28,010
I cookie possono includere alcune informazioni di base

19
00:01:28,010 --> 00:01:31,850
nell'intestazione della richiesta in uscita dal client.

20
00:01:31,850 --> 00:01:37,010
Ora, se vogliamo che molte più informazioni siano tracciate su un client

21
00:01:37,010 --> 00:01:42,420
sul lato server, allora le sessioni espresse ci permettono di farlo.

22
00:01:42,420 --> 00:01:45,140
Studiamo di più sui cookie e

23
00:01:45,140 --> 00:01:49,260
le sessioni Express in modo più dettagliato in questa lezione ed

24
00:01:49,260 --> 00:01:54,380
esploriamo ulteriormente negli esercizi che seguono questa lezione.

25
00:01:56,640 --> 00:01:59,340
Quindi quali sono i cookie HTTP?

26
00:01:59,340 --> 00:02:04,070
I cookie HTTP, come ho detto, sono piccoli pezzi di dati inviati

27
00:02:04,070 --> 00:02:07,610
da un server web e memorizzati sul lato client.

28
00:02:07,610 --> 00:02:12,030
Ora, quasi tutti i browser hanno la possibilità di supportare

29
00:02:12,030 --> 00:02:16,850
la memorizzazione dei cookie sul lato client e includerli automaticamente

30
00:02:16,850 --> 00:02:21,590
nella richiesta quando la richiesta viene inviata a un server specifico.

31
00:02:21,590 --> 00:02:27,127
Quindi ogni richiesta successiva dal

32
00:02:27,127 --> 00:02:32,047
lato client includerà una nuova intestazione lì

33
00:02:32,047 --> 00:02:37,141
con il cookie nell'intestazione della richiesta.

34
00:02:37,141 --> 00:02:41,668
Ora, ovviamente, se avete visto che la stampa popolare ha ottenuto una cattiva reputazione

35
00:02:41,668 --> 00:02:45,450
lì, questo, ovviamente, non è del tutto immeritato.

36
00:02:45,450 --> 00:02:52,880
Ma è saltato fuori misura rispetto a ciò che è veramente la verità.

37
00:02:52,880 --> 00:02:57,760
Quindi prendi tutto quello che leggi sulla stampa popolare sui biscotti e

38
00:02:57,760 --> 00:03:00,570
la loro cattiva reputazione con un chicco di sale.

39
00:03:00,570 --> 00:03:05,040
I cookie sono molto utili per fare un sacco di cose interessanti.

40
00:03:05,040 --> 00:03:09,880
E possiamo garantire che i cookie possano avere un'integrità sufficiente

41
00:03:09,880 --> 00:03:15,070
incorporata in modo che non possano essere manipolati da nessuno nel mezzo.

42
00:03:15,070 --> 00:03:21,640
Ora come funziona questa inclusione delle impostazioni dei cookie nella richiesta in uscita?

43
00:03:21,640 --> 00:03:25,060
Quando un client invia una richiesta al sito server,

44
00:03:25,060 --> 00:03:27,870
se il client è autenticato nel sito server.

45
00:03:27,870 --> 00:03:31,040
Ad esempio, utilizzando l'autenticazione di base,

46
00:03:31,040 --> 00:03:34,950
quindi il server può in cambio, impostare un cookie.

47
00:03:34,950 --> 00:03:39,120
Ora, per impostare un cookie sul sito del client, il server includerà

48
00:03:39,120 --> 00:03:44,090
nel messaggio di risposta un'intestazione con l'intestazione del cookie inviato e

49
00:03:44,090 --> 00:03:46,300
il cookie effettivo nell'intestazione.

50
00:03:46,300 --> 00:03:50,460
Ora, quando il client riceve il messaggio di risposta dal server contenente

51
00:03:50,460 --> 00:03:54,500
l'intestazione Set-Cookie, allora imposterà il cookie sul lato client.

52
00:03:54,500 --> 00:03:59,455
Tale che ogni richiesta successiva che va dal lato client

53
00:03:59,455 --> 00:04:03,602
includerà esplicitamente un campo di intestazione chiamato come cookie e

54
00:04:03,602 --> 00:04:06,846
intestazione effettiva che contiene come valore,

55
00:04:06,846 --> 00:04:13,200
le informazioni sui cookie che sono state inviate dal server nel messaggio di risposta.

56
00:04:13,200 --> 00:04:17,880
Quindi ogni messaggio di richiesta successivo porterà questo cookie nell'intestazione.

57
00:04:17,880 --> 00:04:22,470
In tal modo, quando il server riceve questo messaggio di richiesta, è in grado di esaminare

58
00:04:22,470 --> 00:04:28,490
il cookie e supporre da chi proviene questa richiesta.

59
00:04:28,490 --> 00:04:33,612
Quindi è in grado di riconoscere il cliente guardando le informazioni sui cookie.

60
00:04:33,612 --> 00:04:38,543
Quindi questo è dove i cookie si rivelano molto utili

61
00:04:38,543 --> 00:04:44,019
per poter inviare informazioni di autorizzazione.

62
00:04:44,019 --> 00:04:48,050
Quindi, nel servire includendo nome utente e password come parte dell'

63
00:04:48,050 --> 00:04:51,220
intestazione di autenticazione di base in ogni richiesta in corso.

64
00:04:51,220 --> 00:04:55,120
La prima volta che ti autentichi, invii il tuo nome utente e la tua password e

65
00:04:55,120 --> 00:04:57,140
il server imposta il cookie dalla tua parte.

66
00:04:57,140 --> 00:05:02,070
Successivamente, è sufficiente includere il cookie nella richiesta in uscita.

67
00:05:02,070 --> 00:05:06,789
Ora i cookie possono anche avere una data di scadenza associata ad essi.

68
00:05:06,789 --> 00:05:11,641
Quindi, a quel punto, il cookie sarà considerato scaduto e

69
00:05:11,641 --> 00:05:13,440
non sarà più valido.

70
00:05:13,440 --> 00:05:16,940
Quindi questo è un modo per controllare la durata per la

71
00:05:16,940 --> 00:05:20,340
quale è valida un'autorizzazione.

72
00:05:20,340 --> 00:05:24,350
Venendo su Express stesso, in che modo Express supporta i cookie?

73
00:05:24,350 --> 00:05:28,980
Ora, come abbiamo capito, Express usa un sacco di middleware.

74
00:05:28,980 --> 00:05:34,100
Questo è dove uno dei middleware che arriva chiamato il parser cookie

75
00:05:34,100 --> 00:05:37,092
arriva alla nostra app alle otto.

76
00:05:37,092 --> 00:05:42,580
Il parser di cookie consente al server di impostare un cookie nell'intestazione della risposta.

77
00:05:42,580 --> 00:05:48,350
Quindi questo viene fatto utilizzando res.cookie e il nome e

78
00:05:48,350 --> 00:05:54,160
alcuni valori e le opzioni come vedremo nell'esercizio successivo.

79
00:05:54,160 --> 00:06:00,160
E così i cookie, quando vengono inviati dal lato client, inclusi in quel

80
00:06:00,160 --> 00:06:05,980
messaggio di richiesta vengono analizzati sul lato server Express, utilizzando il parser di cookie.

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

82
00:06:08,383 --> 00:06:13,400
che una volta installato ti consentirà di analizzare i cookie in arrivo.

83
00:06:13,400 --> 00:06:17,280
E poi questi cookie in arrivo verranno aggiunti

84
00:06:17,280 --> 00:06:22,260
nella richiesta come intestazione e possono essere esaminati sul lato server.

85
00:06:23,340 --> 00:06:26,580
Ora, al fine di proteggere l'autenticità del cookie,

86
00:06:26,580 --> 00:06:30,070
i cookie stessi possono essere firmati dal server.

87
00:06:30,070 --> 00:06:35,120
Ora, quando il server firma un cookie, il server utilizza una chiave segreta,

88
00:06:35,120 --> 00:06:38,070
che è nota solo al lato server.

89
00:06:38,070 --> 00:06:42,510
Ora, se sai qualcosa di sicurezza informatica

90
00:06:42,510 --> 00:06:47,210
, crittografia e crittografia, allora capisci cosa

91
00:06:47,210 --> 00:06:49,290
significano firma e chiavi segrete e chiavi pubbliche e tutte queste cose.

92
00:06:49,290 --> 00:06:53,990
Se non lo fai, basta dire che una chiave segreta è

93
00:06:53,990 --> 00:06:59,260
una stringa specifica che solo il server conosce e nessun altro lo sa.

94
00:06:59,260 --> 00:07:05,505
Quindi, quando un server crittografa un cookie, utilizzerà una chiave segreta come firma e

95
00:07:05,505 --> 00:07:11,081
creerà ciò che viene chiamato come codice di autenticazione del messaggio keyy-hash.

96
00:07:11,081 --> 00:07:16,450
E include questo in quel cookie che viene inviato dal server al lato client.

97
00:07:16,450 --> 00:07:21,210
Questo HMAC creato sul lato server può essere fatto solo

98
00:07:21,210 --> 00:07:24,540
da quel server specifico conoscendo quella chiave segreta.

99
00:07:24,540 --> 00:07:27,950
Ora, poiché il server è una risorsa protetta,

100
00:07:27,950 --> 00:07:33,670
solo il server conoscerà la chiave segreta e quindi è molto facile verificare

101
00:07:33,670 --> 00:07:38,320
quando un cookie firmato viene inviato dal lato client al lato server.

102
00:07:38,320 --> 00:07:42,040
Quindi, quando il cookie firmato viene inviato dal lato client al lato server,

103
00:07:42,040 --> 00:07:44,540
il cookie verrà impostato sul lato client, e

104
00:07:44,540 --> 00:07:50,310
quindi tutte le richieste successive includeranno questo cookie firmato nel lato client.

105
00:07:50,310 --> 00:07:54,290
Ora il middleware del parser cookie che abbiamo impostato con il nostro server Express

106
00:07:54,290 --> 00:07:56,630
supporta già i cookie firmati.

107
00:07:56,630 --> 00:08:02,480
Ora per questo, nel parser cookie, si fornirà anche la chiave segreta come

108
00:08:02,480 --> 00:08:07,120
parametro per il parser cookie quando si imposta il middleware del parser cookie.

109
00:08:07,120 --> 00:08:11,970
In tal modo, tutti i cookie saranno firmati in modo appropriato e poi inviati.

110
00:08:11,970 --> 00:08:17,240
E quando il cookie viene analizzato sul lato server nel

111
00:08:17,240 --> 00:08:22,660
messaggio di richiesta in arrivo, questo verrà aggiunto nel messaggio di richiesta come req.signedCookies.

112
00:08:22,660 --> 00:08:27,980
E poi puoi avere un campo specifico che puoi controllare nel cookie firmato.

113
00:08:27,980 --> 00:08:30,890
I cookie sono un modo molto utile per

114
00:08:30,890 --> 00:08:36,380
il tuo cliente essere in grado di inviare informazioni per cui il tuo server riconosce il client.

115
00:08:36,380 --> 00:08:38,490
Ma naturalmente, i cookie hanno dei limiti.

116
00:08:38,490 --> 00:08:42,370
Sono di dimensioni fisse, quindi non possono codificare molte

117
00:08:42,370 --> 00:08:47,090
informazioni sul client che il loro server può recuperare dal cookie.

118
00:08:47,090 --> 00:08:50,710
Il cookie viene utilizzato per ricordare al server

119
00:08:50,710 --> 00:08:53,750
quale client sta inviando la richiesta.

120
00:08:53,750 --> 00:08:58,311
Ora, se si desidera avere un meccanismo più elaborato per tenere traccia delle informazioni su

121
00:08:58,311 --> 00:09:02,889
un client, sul lato server è possibile impostare ciò che viene chiamato come sessioni.

122
00:09:02,889 --> 00:09:09,180
Ora, le sessioni è un meccanismo generico che è disponibile con qualsiasi server.

123
00:09:09,180 --> 00:09:11,850
In particolare, esamineremo Express stesso e

124
00:09:11,850 --> 00:09:17,140
come Express supporta la gestione delle sessioni sul lato server.

125
00:09:17,140 --> 00:09:22,930
Il modo in cui funziona è che la sessione utente è impostata sul lato server.

126
00:09:22,930 --> 00:09:27,430
Quindi questa sessione stessa è una combinazione di un cookie e

127
00:09:27,430 --> 00:09:32,270
un ID di sessione, e il lato server tiene traccia delle informazioni

128
00:09:32,270 --> 00:09:37,250
associate a quell'ID di sessione, o indicizzate da quell'ID di sessione.

129
00:09:37,250 --> 00:09:40,500
Le informazioni di sessione possono avere qualsiasi

130
00:09:40,500 --> 00:09:45,380
quantità di informazioni tracciate sul lato server e indicizzate da quel cookie.

131
00:09:45,380 --> 00:09:50,910
Quindi, quando un client invia una richiesta sul server, dall'interno del cookie

132
00:09:50,910 --> 00:09:56,130
viene recuperato l'ID di sessione e che viene utilizzato come indice nel lato server.

133
00:09:56,130 --> 00:09:56,964
Ad esempio,

134
00:09:56,964 --> 00:10:01,548
se si utilizza un database lato server tale indice sarà l'indice primario in

135
00:10:01,548 --> 00:10:05,456
quel particolare database lato server che tiene traccia delle sessioni.

136
00:10:05,456 --> 00:10:10,486
E quindi, ulteriori informazioni su quella sessione possono essere recuperate e

137
00:10:10,486 --> 00:10:13,761
utilizzate dal server al fine di prendere decisioni su come servire

138
00:10:13,761 --> 00:10:17,380
la richiesta client in arrivo.

139
00:10:17,380 --> 00:10:23,900
Ora, per impostazione predefinita, le sessioni sono memorizzate in memoria sul sito server.

140
00:10:23,900 --> 00:10:28,870
Ora, ovviamente, ciò significa che se il tuo server viene riavviato, la tua memoria

141
00:10:28,870 --> 00:10:33,260
verrà cancellata e quindi tutte le informazioni sulla sessione saranno sparite completamente.

142
00:10:33,260 --> 00:10:37,350
Quindi, invece, molti server ricorderanno all'

143
00:10:37,350 --> 00:10:42,010
utilizzo di una qualche forma di archiviazione permanente in cui vengono tracciate le informazioni di sessione.

144
00:10:42,010 --> 00:10:45,360
Lo storage permanente sul lato server potrebbe essere fatto

145
00:10:45,360 --> 00:10:47,500
attraverso una sorta di archiviazione di file.

146
00:10:47,500 --> 00:10:53,460
O anche sfruttare il fatto che si dispone già di un database sul lato server e

147
00:10:53,460 --> 00:10:56,170
di memorizzare le informazioni sulla sessione sul lato server.

148
00:10:56,170 --> 00:10:59,590
Ad esempio, nel tuo MongoDB stesso.

149
00:10:59,590 --> 00:11:05,620
Ora, nell'esercizio che segue, esamineremo l'uso di un archivio di file per il

150
00:11:05,620 --> 00:11:10,000
monitoraggio delle informazioni di sessione sul lato server.

151
00:11:10,000 --> 00:11:14,450
Un altro aspetto a cui è necessario prestare attenzione è il fatto che se

152
00:11:14,450 --> 00:11:19,540
si dispone di un'implementazione di server distribuito per cui più

153
00:11:19,540 --> 00:11:24,530
server agiscono come server per la manutenzione della richiesta.

154
00:11:24,530 --> 00:11:28,310
Quindi il server di distribuzione dovrebbe essere in grado di accedere alle informazioni di sessione.

155
00:11:29,460 --> 00:11:32,470
Ognuno di questi server dovrebbe essere in grado di accedere alle informazioni di sessione.

156
00:11:32,470 --> 00:11:36,480
Quindi è necessario uno strumento di sessioni di distribuzione sul lato server,

157
00:11:36,480 --> 00:11:40,780
per consentire di supportare più server replicati.

158
00:11:40,780 --> 00:11:45,450
Soprattutto questo è utile quando stiamo cercando di garantire l'affidabilità

159
00:11:45,450 --> 00:11:46,870
del funzionamento del server.

160
00:11:47,960 --> 00:11:52,630
Ora di nuovo, non otterremo troppi dettagli su quelli in questo particolare

161
00:11:52,630 --> 00:11:58,190
corso, ci baseremo sulla comprensione fondamentalmente come funzionano le sessioni Express.

162
00:11:59,710 --> 00:12:02,080
Venendo specificamente a Express e

163
00:12:02,080 --> 00:12:06,080
come la gestione delle sessioni è supportata in Express.

164
00:12:06,080 --> 00:12:10,240
Express utilizza il middleware di sessione express che supporta

165
00:12:10,240 --> 00:12:14,760
l'utilizzo di sessioni in un server Express.

166
00:12:14,760 --> 00:12:18,110
Ora si installa il middleware delle sessioni express.

167
00:12:18,110 --> 00:12:21,140
E nell'esercizio, userò FileStore

168
00:12:21,140 --> 00:12:24,470
come un modo per memorizzare permanentemente le informazioni sulla sessione.

169
00:12:24,470 --> 00:12:30,440
E così includeremo anche il modulo nodo session-file-store che

170
00:12:30,440 --> 00:12:37,305
ci permette di utilizzare i file sul lato server per tenere traccia delle informazioni di sessione.

171
00:12:37,305 --> 00:12:41,120
Vedremo i dettagli nell'esercizio che segue.

172
00:12:41,120 --> 00:12:46,247
E poi una volta fatto che la sessione stessa sarà impostata con il nuovo

173
00:12:46,247 --> 00:12:51,690
server express dichiarando il middleware qui come sessione che prende

174
00:12:51,690 --> 00:12:57,390
un certo insieme di opzioni come parametro qui.

175
00:12:57,390 --> 00:13:02,200
Le opzioni includono il nome della sessione, quindi daremo l'ID di sessione per

176
00:13:02,200 --> 00:13:03,500
la sessione particolare.

177
00:13:03,500 --> 00:13:07,500
E poi si fornirà anche il segreto, una chiave segreta che viene utilizzata per

178
00:13:07,500 --> 00:13:12,460
codificare il cookie firmato che verrà inviato al lato client.

179
00:13:12,460 --> 00:13:17,960
E poi anche ulteriori informazioni tra cui SaveUninitialized, che

180
00:13:19,190 --> 00:13:24,625
sarà un flag che viene utilizzato e anche un flag di salvataggio che viene utilizzato.

181
00:13:24,625 --> 00:13:28,760
Verranno esaminati alcuni dettagli di queste opzioni nella diapositiva successiva.

182
00:13:28,760 --> 00:13:31,390
Quindi tutte queste opzioni sono specificate qui.

183
00:13:31,390 --> 00:13:36,945
E se sei FileStore come la memoria permanente per le tue sessioni,

184
00:13:36,945 --> 00:13:42,130
allora dichiareremo che anche nelle opzioni di sessione lì.

185
00:13:42,130 --> 00:13:47,450
Quindi questo è il modo in cui avremmo impostato una sessione sul lato server espresso

186
00:13:47,450 --> 00:13:49,510
utilizzando il Middleware sessione express.

187
00:13:49,510 --> 00:13:55,540
E il Middleware di sessione express, quando il client invia queste informazioni,

188
00:13:55,540 --> 00:13:58,980
questo verrà analizzato sul lato server e

189
00:13:58,980 --> 00:14:04,640
ciò comporterà l'aggiunta di una proprietà chiamata sessione all'oggetto richiesta.

190
00:14:04,640 --> 00:14:09,460
Quindi queste informazioni di sessione saranno accessibili nell'

191
00:14:09,460 --> 00:14:11,505
oggetto richiesta come req.session.

192
00:14:11,505 --> 00:14:16,221
Quindi la req.session porterà ulteriori informazioni su quella particolare sessione

193
00:14:16,221 --> 00:14:18,325
per quel particolare client.

194
00:14:18,325 --> 00:14:22,979
Ora, una volta che questa sessione, la richiesta in arrivo viene analizzata dal middleware della sessione,

195
00:14:22,979 --> 00:14:28,957
la proprietà req.session verrà aggiunta all'

196
00:14:28,957 --> 00:14:33,447
oggetto messaggio di richiesta in arrivo che utilizza esplicitamente.

197
00:14:33,447 --> 00:14:40,097
Quindi, dopo che la sessione è stata analizzata, la proprietà della sessione diretta sarà disponibile e

198
00:14:40,097 --> 00:14:46,165
possiamo esaminarlo anche per verificare quale client ha inviato questa richiesta.

199
00:14:46,165 --> 00:14:50,900
Quando impostano il loro oggetto sessione sul sito server,

200
00:14:50,900 --> 00:14:54,760
come abbiamo visto, siamo in grado di impostare varie opzioni per quel sito server.

201
00:14:54,760 --> 00:14:59,790
Il cookie, le opzioni dal cookie ID di sessione e il valore predefinito per

202
00:14:59,790 --> 00:15:04,275
il cookie saranno come mostrato qui, che è path: '/',

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

204
00:15:07,700 --> 00:15:13,450
Quindi questo sarà il valore predefinito del cookie che verrà memorizzato sul pacchetto

205
00:15:13,450 --> 00:15:17,680
e inviato al lato del client come cookie firmato.

206
00:15:17,680 --> 00:15:23,306
E questo sarebbe incluso in ogni richiesta in arrivo dal sito del cliente.

207
00:15:23,306 --> 00:15:28,080
Quindi il genid è la funzione che genera l'ID di sessione.

208
00:15:28,080 --> 00:15:33,830
L' impostazione predefinita è utilizzare l'UUID del server stesso come ID generale.

209
00:15:33,830 --> 00:15:38,720
Quindi il flag di salvataggio, se è vero, costringe una sessione a essere salvata nuovamente

210
00:15:38,720 --> 00:15:41,470
nell'archivio anche se non viene modificata dalla richiesta.

211
00:15:41,470 --> 00:15:44,230
A volte la richiesta in arrivo può

212
00:15:45,580 --> 00:15:50,200
contenere la necessità di modificare le informazioni di sessione sul lato server.

213
00:15:50,200 --> 00:15:54,300
E quindi, se le informazioni sulla sessione vengono modificate, dovrà essere persistente.

214
00:15:54,300 --> 00:15:56,290
In caso contrario, non è necessario persistere.

215
00:15:56,290 --> 00:16:00,454
Ma se si imposta il flag di risalvataggio su true, anche se le informazioni sulla sessione

216
00:16:00,454 --> 00:16:06,030
sul server non vengono modificate dalla richiesta client in arrivo, verrà comunque salvata nuovamente.

217
00:16:06,030 --> 00:16:09,980
Il flag successivo che abbiamo esaminato era SaveUninitialized.

218
00:16:09,980 --> 00:16:14,620
Se questo è vero, creerà una sessione appena creata senza alcuna modifica

219
00:16:14,620 --> 00:16:16,540
da salvare dell'archivio sessioni.

220
00:16:16,540 --> 00:16:21,164
Ora imposteremo questo su false per impostazione predefinita, il che significa che ci sarà solo

221
00:16:21,164 --> 00:16:25,008
tenere traccia di quelle sessioni che sono autorizzati sul server.

222
00:16:25,008 --> 00:16:30,955
Ora il segreto, come vediamo, è la chiave segreta che viene utilizzata per firmare il cookie,

223
00:16:30,955 --> 00:16:36,310
e il negozio stesso specifica l'istanza di archivio sessione che viene utilizzata.

224
00:16:36,310 --> 00:16:39,810
L' impostazione predefinita è utilizzare l'archivio in memoria.

225
00:16:39,810 --> 00:16:42,950
È possibile specificare l'archivio file o l'archivio Mongo per

226
00:16:42,950 --> 00:16:46,000
memorizzare le informazioni sulla sessione e così via.

227
00:16:46,000 --> 00:16:51,590
Quindi, una volta specificate queste informazioni per il middleware di sessione espressa,

228
00:16:51,590 --> 00:16:57,350
la sessione verrà configurata in modo appropriato e quindi verrà tracciata sul lato server.

229
00:16:57,350 --> 00:17:02,430
Ogni richiesta client verrà quindi mappata alle informazioni di sessione

230
00:17:02,430 --> 00:17:08,260
sul lato server quando la richiesta client viene analizzata dal middleware sessione express.

231
00:17:08,260 --> 00:17:12,960
E il req.session verrà aggiunto nell'oggetto richiesta.

232
00:17:14,150 --> 00:17:19,010
Con questa comprensione dei cookie e delle sessioni express, passiamo

233
00:17:19,010 --> 00:17:24,050
all'esercizio in cui vedremo come utilizzeremo prima i cookie.

234
00:17:24,050 --> 00:17:29,360
E poi vedremo come faremo uso di sessioni Express Express

235
00:17:29,360 --> 00:17:35,121
all'interno della nostra applicazione API REST Express su cui abbiamo lavorato finora.

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