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

2
00:00:04,649 --> 00:00:08,820
In der vorherigen Lektion haben wir etwas über die grundlegende Authentifizierung erfahren.

3
00:00:08,820 --> 00:00:14,398
Wir haben gesehen, dass der Client bei der Standardauthentifizierung explizit weiter

4
00:00:14,398 --> 00:00:19,720
in das Autorisierungsfeld mit dem Benutzernamen und dem

5
00:00:19,720 --> 00:00:24,100
Passwort für jede Anfrage hinzufügen muss, die der Client an die Serverseite sendet.

6
00:00:24,100 --> 00:00:27,750
Jetzt ist das perfekt für die einfache Authentifizierung.

7
00:00:27,750 --> 00:00:33,520
Cookies sind ein weiterer Mechanismus, der es Ihrem Server ermöglicht,

8
00:00:33,520 --> 00:00:38,700
erwarten zu können, dass der Client einige Informationen auf der Client-Seite speichert und

9
00:00:38,700 --> 00:00:43,370
diese Informationen explizit in jede ausgehende Anfrage einbezieht.

10
00:00:43,370 --> 00:00:47,360
Anstatt also Ihren Base-64-codierten Benutzernamen und Ihr

11
00:00:47,360 --> 00:00:53,710
Passwort wie bei der Basisauthentifizierung mit Cookies einzufügen,

12
00:00:53,710 --> 00:00:58,130
kann Ihr Server eine explizite Information auf der Clientseite einrichten

13
00:00:58,130 --> 00:01:02,520
, die dann in jeder ausgehenden Anfrage von der Clientseite enthalten wird.

14
00:01:03,750 --> 00:01:08,740
Wenn Ihr Server Informationen über Ihren

15
00:01:08,740 --> 00:01:15,180
Client verfolgen möchte, kann der Server explizit einen Sitzungsverfolgungsmechanismus einrichten.

16
00:01:15,180 --> 00:01:20,720
Jetzt sind Cookies klein und können nicht viele Informationen darin speichern,

17
00:01:20,720 --> 00:01:25,230
und dies kann natürlich nicht in die ausgehende Anfrage aufgenommen werden.

18
00:01:25,230 --> 00:01:28,010
Cookies können einige grundlegende Informationen

19
00:01:28,010 --> 00:01:31,850
in der Kopfzeile der ausgehenden Anfrage des Kunden enthalten.

20
00:01:31,850 --> 00:01:37,010
Nun, wenn wir wollen, dass viel mehr Informationen über einen Client

21
00:01:37,010 --> 00:01:42,420
auf der Serverseite verfolgt werden, dann ermöglichen Express-Sessions es uns, dies zu tun.

22
00:01:42,420 --> 00:01:45,140
Lassen Sie uns

23
00:01:45,140 --> 00:01:49,260
in dieser Lektion mehr über Cookies und Express-Sitzungen näher studieren und

24
00:01:49,260 --> 00:01:54,380
sie auch in den Übungen, die dieser Vorlesung folgen, weiter untersuchen.

25
00:01:56,640 --> 00:01:59,340
Was sind HTTP-Cookies?

26
00:01:59,340 --> 00:02:04,070
HTTP-Cookies sind, wie ich bereits erwähnt habe, kleine Daten, die

27
00:02:04,070 --> 00:02:07,610
von einem Webserver gesendet werden und auf der Client-Seite gespeichert werden.

28
00:02:07,610 --> 00:02:12,030
Jetzt haben fast alle Browser die Möglichkeit,

29
00:02:12,030 --> 00:02:16,850
das Speichern von Cookies auf der Clientseite zu unterstützen und sie automatisch

30
00:02:16,850 --> 00:02:21,590
in die Anfrage aufzunehmen, wenn die Anfrage an einen bestimmten Server gesendet wird.

31
00:02:21,590 --> 00:02:27,127
Jede nachfolgende Anfrage von der

32
00:02:27,127 --> 00:02:32,047
Clientseite enthält also einen neuen Header

33
00:02:32,047 --> 00:02:37,141
mit dem Cookie in der Anforderungskopfzeile.

34
00:02:37,141 --> 00:02:41,668
Nun offensichtlich, wenn Sie gesehen haben, dass die Presse

35
00:02:41,668 --> 00:02:45,450
dort einen schlechten Ruf bekommen hat, ist das natürlich nicht völlig unverdient.

36
00:02:45,450 --> 00:02:52,880
Aber es ist weit aus dem Verhältnis geblasen, als das, was wirklich die Wahrheit ist.

37
00:02:52,880 --> 00:02:57,760
Also nehmen Sie alles, was Sie in der populären Presse über Cookies und

38
00:02:57,760 --> 00:03:00,570
ihren schlechten Ruf mit einem Korn Salz lesen.

39
00:03:00,570 --> 00:03:05,040
Cookies sind sehr nützlich, um viele interessante Dinge zu tun.

40
00:03:05,040 --> 00:03:09,880
Und wir können sicherstellen, dass Cookies eine ausreichende

41
00:03:09,880 --> 00:03:15,070
Integrität aufweisen können, damit sie von niemandem manipuliert werden können.

42
00:03:15,070 --> 00:03:21,640
Wie funktioniert diese Cookie-Einstellung Aufnahme in die ausgehende Anfrage?

43
00:03:21,640 --> 00:03:25,060
Wenn ein Client eine Anforderung an den Serverstandort sendet,

44
00:03:25,060 --> 00:03:27,870
wenn der Client am Serverstandort authentifiziert ist.

45
00:03:27,870 --> 00:03:31,040
Zum Beispiel, mit der Basisauthentifizierung,

46
00:03:31,040 --> 00:03:34,950
dann kann der Server im Gegenzug, ein Cookie einrichten.

47
00:03:34,950 --> 00:03:39,120
Um nun ein Cookie auf der Website des Clients einzurichten, wird der Server in die

48
00:03:39,120 --> 00:03:44,090
Antwortnachricht einen Header mit dem gesendeten Cookie-Header und

49
00:03:44,090 --> 00:03:46,300
dem eigentlichen Cookie im Header aufnehmen.

50
00:03:46,300 --> 00:03:50,460
Wenn der Client nun die Antwortnachricht von dem Server empfängt,

51
00:03:50,460 --> 00:03:54,500
der den Set-Cookie-Header enthält, wird das Cookie auf der Clientseite eingerichtet.

52
00:03:54,500 --> 00:03:59,455
So dass jede nachfolgende Anfrage, die von der Client-Seite geht,

53
00:03:59,455 --> 00:04:03,602
explizit ein Header-Feld namens Cookie und

54
00:04:03,602 --> 00:04:06,846
tatsächlichen Header enthält, der als Wert

55
00:04:06,846 --> 00:04:13,200
die Cookie-Informationen enthält, die vom Server in der Antwortnachricht gesendet wurden.

56
00:04:13,200 --> 00:04:17,880
Daher wird jede nachfolgende Anforderungsnachricht dieses Cookie in der Kopfzeile tragen.

57
00:04:17,880 --> 00:04:22,470
Wenn der Server diese Anforderungsnachricht erhält, ist er in der Lage,

58
00:04:22,470 --> 00:04:28,490
den Cookie zu untersuchen und zu vermuten, von wem diese Anfrage kommt.

59
00:04:28,490 --> 00:04:33,612
So ist es in der Lage, den Client durch Blick auf die Cookie-Informationen zu erkennen.

60
00:04:33,612 --> 00:04:38,543
Hier erweisen sich Cookies als sehr nützlich, um

61
00:04:38,543 --> 00:04:44,019
Autorisierungsinformationen senden zu können.

62
00:04:44,019 --> 00:04:48,050
Also in der Bereitstellung einschließlich Benutzername und Passwort als Teil der grundlegenden

63
00:04:48,050 --> 00:04:51,220
Authentifizierung Header in jeder laufenden Anfrage.

64
00:04:51,220 --> 00:04:55,120
Wenn Sie sich das erste Mal authentifizieren, senden Sie Ihren Benutzernamen und Ihr Passwort und

65
00:04:55,120 --> 00:04:57,140
der Server richtet das Cookie auf Ihrer Seite ein.

66
00:04:57,140 --> 00:05:02,070
Anschließend müssen Sie das Cookie nur in die ausgehende Anfrage aufnehmen.

67
00:05:02,070 --> 00:05:06,789
Jetzt können Cookies auch ein Ablaufdatum mit ihnen verbunden sein.

68
00:05:06,789 --> 00:05:11,641
Somit gilt der Cookie zu diesem Zeitpunkt als abgelaufen und ist

69
00:05:11,641 --> 00:05:13,440
nicht mehr gültig.

70
00:05:13,440 --> 00:05:16,940
Das ist also eine Möglichkeit, die Dauer zu kontrollieren

71
00:05:16,940 --> 00:05:20,340
, für die eine Autorisierung gültig ist.

72
00:05:20,340 --> 00:05:24,350
Wie unterstützt Express Cookies?

73
00:05:24,350 --> 00:05:28,980
Jetzt, wie wir verstehen, verwendet Express eine Menge Middleware.

74
00:05:28,980 --> 00:05:34,100
Dies ist, wo einer der Middlewares, die als Cookie-Parser

75
00:05:34,100 --> 00:05:37,092
kommt, um acht Uhr zu unserer App kommt.

76
00:05:37,092 --> 00:05:42,580
Der Cookie-Parser ermöglicht es dem Server, ein Cookie im Antwort-Header einzurichten.

77
00:05:42,580 --> 00:05:48,350
Dies geschieht also durch die Verwendung von res.cookie und den Namen und

78
00:05:48,350 --> 00:05:54,160
bestimmte Werte und die Optionen, wie wir in der Übung später sehen werden.

79
00:05:54,160 --> 00:06:00,160
Und so werden Cookies, wenn sie von der Client-Seite gesendet werden, die in dieser

80
00:06:00,160 --> 00:06:05,980
Anforderungsnachricht enthalten sind, auf der Express-Serverseite mit dem Cookie-Parser analysiert.

81
00:06:05,980 --> 00:06:08,383
Die Cookie-Parser-Middleware

82
00:06:08,383 --> 00:06:13,400
, mit der Sie bei der Installation die eingehenden Cookies analysieren können.

83
00:06:13,400 --> 00:06:17,280
Und dann werden diese eingehenden Cookies

84
00:06:17,280 --> 00:06:22,260
als Header in die Anfrage eingefügt und können serverseitig untersucht werden.

85
00:06:23,340 --> 00:06:26,580
Um die Authentizität des Cookies zu schützen,

86
00:06:26,580 --> 00:06:30,070
können die Cookies selbst vom Server signiert werden.

87
00:06:30,070 --> 00:06:35,120
Wenn der Server nun ein Cookie signiert, verwendet der Server einen geheimen Schlüssel

88
00:06:35,120 --> 00:06:38,070
, der nur der Serverseite bekannt ist.

89
00:06:38,070 --> 00:06:42,510
Wenn Sie jetzt etwas über Computersicherheit und Kryptographie und

90
00:06:42,510 --> 00:06:47,210
Verschlüsselung wissen, dann verstehen Sie, was Signieren und geheime Schlüssel und

91
00:06:47,210 --> 00:06:49,290
öffentliche Schlüssel und all diese Dinge bedeuten.

92
00:06:49,290 --> 00:06:53,990
Wenn Sie dies nicht tun, genügt es, zu sagen, dass ein geheimer Schlüssel

93
00:06:53,990 --> 00:06:59,260
eine bestimmte Zeichenfolge ist, die nur der Server kennt und niemand sonst weiß.

94
00:06:59,260 --> 00:07:05,505
Wenn ein Server also ein Cookie verschlüsselt, verwendet er einen geheimen Schlüssel als Signatur und

95
00:07:05,505 --> 00:07:11,081
erstellt, was als Schlüssel-Hash-Nachrichtenauthentifizierungscode bezeichnet wird.

96
00:07:11,081 --> 00:07:16,450
Und schließt dies in diesem Cookie, das vom Server an die Client-Seite gesendet wird.

97
00:07:16,450 --> 00:07:21,210
Dieser HMAC, der auf der Serverseite erstellt wird, kann nur

98
00:07:21,210 --> 00:07:24,540
von diesem bestimmten Server ausgeführt werden, der diesen geheimen Schlüssel kennt.

99
00:07:24,540 --> 00:07:27,950
Jetzt, da der Server eine geschützte Ressource ist, so dass

100
00:07:27,950 --> 00:07:33,670
nur der Server den geheimen Schlüssel kennen und so ist es sehr einfach zu überprüfen,

101
00:07:33,670 --> 00:07:38,320
wenn ein signiertes Cookie von der Client-Seite auf die Serverseite gesendet wird.

102
00:07:38,320 --> 00:07:42,040
Wenn also das signierte Cookie von der Client-Seite auf die Serverseite gesendet wird,

103
00:07:42,040 --> 00:07:44,540
wird das Cookie auf der Clientseite eingerichtet, und

104
00:07:44,540 --> 00:07:50,310
dann werden alle nachfolgenden Anfragen dieses signierte Cookie auf der Clientseite enthalten.

105
00:07:50,310 --> 00:07:54,290
Die Cookie-Parser-Middleware, die wir mit unserem Express-Server eingerichtet haben,

106
00:07:54,290 --> 00:07:56,630
unterstützt nun bereits signierte Cookies.

107
00:07:56,630 --> 00:08:02,480
Nun geben Sie im Cookie-Parser auch den geheimen Schlüssel als

108
00:08:02,480 --> 00:08:07,120
Parameter für den Cookie-Parser an, wenn Sie die Cookie-Parser-Middleware einrichten.

109
00:08:07,120 --> 00:08:11,970
Dabei werden alle Cookies entsprechend signiert und anschließend versendet.

110
00:08:11,970 --> 00:08:17,240
Und wenn das Cookie auf der Serverseite in der eingehenden

111
00:08:17,240 --> 00:08:22,660
Anforderungsnachricht analysiert wird, wird dies in die Anforderungsnachricht als Req.signedCookies eingefügt.

112
00:08:22,660 --> 00:08:27,980
Und dann können Sie ein bestimmtes Feld haben, das Sie in den signierten Cookie einchecken können.

113
00:08:27,980 --> 00:08:30,890
Cookies sind sehr nützlich, um

114
00:08:30,890 --> 00:08:36,380
Ihren Kunden Informationen senden zu können, wodurch Ihr Server den Client erkennt.

115
00:08:36,380 --> 00:08:38,490
Aber natürlich haben Cookies Einschränkungen.

116
00:08:38,490 --> 00:08:42,370
Sie haben eine feste Größe, so dass sie nicht viele Informationen

117
00:08:42,370 --> 00:08:47,090
über den Client codieren können, die ihr Server aus dem Cookie abrufen kann.

118
00:08:47,090 --> 00:08:50,710
Das Cookie wird verwendet, um den Server nur daran zu erinnern

119
00:08:50,710 --> 00:08:53,750
, welcher Client die Anfrage sendet.

120
00:08:53,750 --> 00:08:58,311
Wenn Sie nun einen aufwändigeren Mechanismus haben möchten, um Informationen über

121
00:08:58,311 --> 00:09:02,889
einen Client zu verfolgen, können Sie auf der Serverseite einrichten, was als Sitzungen bezeichnet werden.

122
00:09:02,889 --> 00:09:09,180
Jetzt sind Sitzungen ein generischer Mechanismus, der für alle Server verfügbar ist.

123
00:09:09,180 --> 00:09:11,850
Insbesondere betrachten wir Express selbst und

124
00:09:11,850 --> 00:09:17,140
wie Express die Sitzungsverwaltung auf der Serverseite unterstützt.

125
00:09:17,140 --> 00:09:22,930
Die Funktionsweise besteht darin, dass die Benutzersitzung auf der Serverseite eingerichtet ist.

126
00:09:22,930 --> 00:09:27,430
Diese Sitzung selbst ist also eine Kombination aus einem Cookie und

127
00:09:27,430 --> 00:09:32,270
einer Sitzungs-ID, und die serverseitige Verfolgung von Informationen

128
00:09:32,270 --> 00:09:37,250
, die mit dieser Sitzungs-ID verknüpft sind oder durch diese Sitzungs-ID indiziert werden.

129
00:09:37,250 --> 00:09:40,500
Die Sitzungsinformationen selbst können

130
00:09:40,500 --> 00:09:45,380
beliebig viele Informationen auf der Serverseite verfolgt und von diesem Cookie indiziert werden.

131
00:09:45,380 --> 00:09:50,910
Wenn also ein Client eine Anfrage über den Server sendet, dann

132
00:09:50,910 --> 00:09:56,964
wird aus dem Cookie die Sitzungs-ID abgerufen und die als Index auf die Serverseite verwendet wird.

133
00:09:56,964 --> 00:10:01,548
Wenn Sie beispielsweise eine serverseitige Datenbank verwenden, ist dieser Index der primäre Index in

134
00:10:01,548 --> 00:10:05,456
dieser bestimmten serverseitigen Datenbank, die die Sitzungen verfolgt.

135
00:10:05,456 --> 00:10:10,486
Dadurch können zusätzliche Informationen über diese Sitzung abgerufen und

136
00:10:10,486 --> 00:10:13,761
von Ihrem Server verwendet werden, um Entscheidungen darüber zu treffen, wie

137
00:10:13,761 --> 00:10:17,380
er die eingehende Clientanfrage bedient.

138
00:10:17,380 --> 00:10:23,900
Jetzt werden die Sitzungen standardmäßig im Speicher auf der Server-Site gespeichert.

139
00:10:23,900 --> 00:10:28,870
Nun offensichtlich, was das bedeutet, ist, dass, wenn Ihr Server neu gestartet

140
00:10:28,870 --> 00:10:33,260
wird, Ihr Speicher gelöscht wird und so alle Sitzungsinformationen vollständig verschwunden sind.

141
00:10:33,260 --> 00:10:37,350
Stattdessen werden viele Server auf eine

142
00:10:37,350 --> 00:10:42,010
Form des permanenten Speichers zurückgreifen, in dem die Sitzungsinformationen verfolgt werden.

143
00:10:42,010 --> 00:10:45,360
Der permanente Speicher auf der Serverseite könnte entweder

144
00:10:45,360 --> 00:10:47,500
durch eine Art Dateispeicher erfolgen.

145
00:10:47,500 --> 00:10:53,460
Oder nutzen Sie sogar die Tatsache, dass Sie bereits eine Datenbank auf der Serverseite haben und dann

146
00:10:53,460 --> 00:10:56,170
die Sitzungsinformationen auf der Serverseite speichern.

147
00:10:56,170 --> 00:10:59,590
Zum Beispiel in Ihrer MongoDB selbst.

148
00:10:59,590 --> 00:11:05,620
In der folgenden Übung werden wir uns nun die Verwendung eines Dateispeichers für die

149
00:11:05,620 --> 00:11:10,000
Verfolgung von Sitzungsinformationen auf der Serverseite ansehen.

150
00:11:10,000 --> 00:11:14,450
Ein weiterer Aspekt, auf den Sie achten müssen, ist die Tatsache, dass, wenn

151
00:11:14,450 --> 00:11:19,540
Sie eine verteilte Serverimplementierung haben, bei der

152
00:11:19,540 --> 00:11:24,530
mehrere Server als Server für die Wartung der Anfrage fungieren.

153
00:11:24,530 --> 00:11:28,310
Dann sollte der Verteilerserver in der Lage sein, auf die Sitzungsinformationen zuzugreifen.

154
00:11:29,460 --> 00:11:32,470
Jeder dieser Server sollte auf die Sitzungsinformationen zugreifen können.

155
00:11:32,470 --> 00:11:36,480
Sie benötigen also ein Verteiler-Session-Tool auf der Serverseite,

156
00:11:36,480 --> 00:11:40,780
damit Sie mehrere replizierte Server unterstützen können.

157
00:11:40,780 --> 00:11:45,450
Dies ist besonders nützlich, wenn wir versuchen, die Zuverlässigkeit

158
00:11:45,450 --> 00:11:46,870
des Serverbetriebs zu gewährleisten.

159
00:11:47,960 --> 00:11:52,630
Jetzt wieder, wir werden nicht zu viele Details über die in diesem speziellen

160
00:11:52,630 --> 00:11:58,190
Kurs bekommen, wir werden uns darauf verlassen, im Grunde zu verstehen, wie Express-Sitzungen funktionieren.

161
00:11:59,710 --> 00:12:02,080
Speziell zu Express kommen und

162
00:12:02,080 --> 00:12:06,080
wie die Sitzungsverwaltung in Express unterstützt wird.

163
00:12:06,080 --> 00:12:10,240
Express verwendet die Express-Sitzungs-Middleware, die

164
00:12:10,240 --> 00:12:14,760
die Verwendung von Sitzungen auf einem Express-Server unterstützt.

165
00:12:14,760 --> 00:12:18,110
Jetzt installieren Sie die Express-Sessions Middleware.

166
00:12:18,110 --> 00:12:21,140
Und in der Übung werde ich den FileStore verwenden, um

167
00:12:21,140 --> 00:12:24,470
die Sitzungsinformationen dauerhaft zu speichern.

168
00:12:24,470 --> 00:12:30,440
Und so werden wir auch das Sitzungsdatei-Speicher-Knoten-Modul, das

169
00:12:30,440 --> 00:12:37,305
es uns ermöglicht, die Dateien auf der Serverseite zu verwenden, um die Sitzungsinformationen zu verfolgen.

170
00:12:37,305 --> 00:12:41,120
Wir werden die Details in der folgenden Übung sehen.

171
00:12:41,120 --> 00:12:46,247
Und dann, sobald wir tun, wird Ihre Sitzung selbst mit dem neuen

172
00:12:46,247 --> 00:12:51,690
Express-Server eingerichtet werden, indem Sie die Middleware hier als Sitzung deklarieren, die

173
00:12:51,690 --> 00:12:57,390
einen bestimmten Satz von Optionen als Parameter hier nimmt.

174
00:12:57,390 --> 00:13:02,200
Die Optionen enthalten den Namen für die Sitzung, daher geben wir die Sitzungs-ID für

175
00:13:02,200 --> 00:13:03,500
die jeweilige Sitzung an.

176
00:13:03,500 --> 00:13:07,500
Und dann geben Sie auch das Geheimnis an, einen geheimen Schlüssel, der für die

177
00:13:07,500 --> 00:13:12,460
Kodierung des signierten Cookies verwendet wird, der an die Client-Seite gesendet wird.

178
00:13:12,460 --> 00:13:17,960
Und dann auch zusätzliche Informationen einschließlich SaveUnInitialized, die

179
00:13:19,190 --> 00:13:24,625
ein Flag sein wird, das verwendet wird, und auch ein Resave Flag, das verwendet wird.

180
00:13:24,625 --> 00:13:28,760
Einige der Details dieser Optionen werden in der nächsten Folie betrachtet.

181
00:13:28,760 --> 00:13:31,390
Also alle diese Optionen sind hier angegeben.

182
00:13:31,390 --> 00:13:36,945
Und wenn Sie FileStore als permanenter Speicher für Ihre Sitzungen

183
00:13:36,945 --> 00:13:42,130
sind, dann werden wir das auch in den Sitzungsoptionen dort erklären.

184
00:13:42,130 --> 00:13:47,450
So würden wir eine Sitzung auf der Express-Serverseite

185
00:13:47,450 --> 00:13:49,510
mit der Express-Sitzung Middleware einrichten.

186
00:13:49,510 --> 00:13:55,540
Und die Express-Sitzung Middleware, wenn der Client diese Informationen sendet,

187
00:13:55,540 --> 00:13:58,980
wird dies auf der Serverseite analysiert und

188
00:13:58,980 --> 00:14:04,640
dies führt dazu, dass eine Eigenschaft namens Session dem Anforderungsobjekt hinzugefügt wird.

189
00:14:04,640 --> 00:14:09,460
Auf diese Sitzungsinformationen kann also im

190
00:14:09,460 --> 00:14:11,505
Anforderungsobjekt als req.session zugegriffen werden.

191
00:14:11,505 --> 00:14:16,221
Die req.session wird also zusätzliche Informationen über diese bestimmte Sitzung

192
00:14:16,221 --> 00:14:18,325
für diesen bestimmten Client enthalten.

193
00:14:18,325 --> 00:14:22,979
Sobald diese Sitzung eingehende Anforderung von der Sitzungs-Middleware analysiert wird,

194
00:14:22,979 --> 00:14:28,957
wird die req.session Eigenschaft dem eingehenden

195
00:14:28,957 --> 00:14:33,447
Anforderungsnachrichtungsobjekt hinzugefügt, das Express verwendet.

196
00:14:33,447 --> 00:14:40,097
Also, nachdem die Sitzung geparst wurde, wird die direkte Sitzungseigenschaft verfügbar sein und

197
00:14:40,097 --> 00:14:46,165
wir können das auch untersuchen, um zu überprüfen, welcher Client diese Anfrage gesendet hat.

198
00:14:46,165 --> 00:14:50,900
Wenn sie ihr Sitzungsobjekt auf der Server-Site

199
00:14:50,900 --> 00:14:54,760
einrichten, wie wir gesehen haben, können wir verschiedene Optionen für diese Server-Site einrichten.

200
00:14:54,760 --> 00:14:59,790
Das Cookie, die Optionen aus dem Session-ID-Cookie und der Standardwert für

201
00:14:59,790 --> 00:15:04,275
das Cookie werden wie hier gezeigt, was Pfad ist: '/',

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

203
00:15:07,700 --> 00:15:13,450
Dies wird also der Standardwert des Cookies sein, der auf dem Paket gespeichert

204
00:15:13,450 --> 00:15:17,680
und als signiertes Cookie an die Seite des Kunden gesendet wird.

205
00:15:17,680 --> 00:15:23,306
Und dies würde in jeder eingehenden Anfrage vom Standort des Kunden enthalten sein.

206
00:15:23,306 --> 00:15:28,080
Dann ist die genid die Funktion, die die Sitzungs-ID generiert.

207
00:15:28,080 --> 00:15:33,830
Standardmäßig wird die UUID des Servers selbst als allgemeine ID verwendet.

208
00:15:33,830 --> 00:15:38,720
Wenn es wahr ist, erzwingt das Resave Flag dann, dass eine Sitzung wieder

209
00:15:38,720 --> 00:15:41,470
im Speicher gespeichert wird, auch wenn sie nicht von der Anforderung geändert wird.

210
00:15:41,470 --> 00:15:44,230
Manchmal

211
00:15:45,580 --> 00:15:50,200
enthält die eingehende Anforderung möglicherweise eine Notwendigkeit, die Sitzungsinformationen auf der Serverseite zu ändern.

212
00:15:50,200 --> 00:15:54,300
Wenn die Sitzungsinformationen geändert werden, muss sie dauerhaft sein.

213
00:15:54,300 --> 00:15:56,290
Wenn nicht, dann müssen Sie es nicht anhalten.

214
00:15:56,290 --> 00:16:00,454
Wenn Sie jedoch das Flag „Erneut speichern“ auf „true“ setzen, werden

215
00:16:00,454 --> 00:16:06,030
die Sitzungsinformationen auf dem Server nicht von der eingehenden Clientanforderung geändert werden, dennoch erneut gespeichert.

216
00:16:06,030 --> 00:16:09,980
Das nächste Flag, das wir uns angesehen haben, war SaveUninitialized.

217
00:16:09,980 --> 00:16:14,620
Wenn dies der Fall ist, wird eine neu erstellte Sitzung erstellt, ohne dass

218
00:16:14,620 --> 00:16:16,540
Änderungen am Sitzungsspeicher gespeichert werden müssen.

219
00:16:16,540 --> 00:16:21,164
Jetzt werden wir dies standardmäßig auf false setzen, was bedeutet, dass wir nur

220
00:16:21,164 --> 00:16:25,008
die Sitzungen verfolgen, die auf dem Server autorisiert sind.

221
00:16:25,008 --> 00:16:30,955
Nun ist das Geheimnis, wie wir sehen, der geheime Schlüssel, der zum Signieren des Cookies verwendet wird,

222
00:16:30,955 --> 00:16:36,310
und der Speicher selbst gibt die Session-Store-Instanz, die verwendet wird.

223
00:16:36,310 --> 00:16:39,810
Standardmäßig wird der Speicher im Speicher verwendet.

224
00:16:39,810 --> 00:16:42,950
Sie können den Dateispeicher oder den Mongo-Speicher zum

225
00:16:42,950 --> 00:16:46,000
Speichern dieser Sitzungsinformationen angeben usw.

226
00:16:46,000 --> 00:16:51,590
Wenn Sie also diese Informationen für Ihre Express-Sitzungs-Middleware angeben,

227
00:16:51,590 --> 00:16:57,350
wird die Sitzung entsprechend eingerichtet und so auf der Serverseite verfolgt.

228
00:16:57,350 --> 00:17:02,430
Jede Clientanforderung wird dann den Sitzungsinformationen auf der

229
00:17:02,430 --> 00:17:08,260
Serverseite zugeordnet, wenn die Clientanforderung von der Express-Sitzungs-Middleware analysiert wird.

230
00:17:08,260 --> 00:17:12,960
Und die req.session wird dem Anforderungsobjekt hinzugefügt.

231
00:17:14,150 --> 00:17:19,010
Mit diesem Verständnis von Cookies und Express-Sitzungen, lassen Sie uns

232
00:17:19,010 --> 00:17:24,050
auf die Übung gehen, wo wird prüfen, wie wir die Verwendung von Cookies zuerst machen.

233
00:17:24,050 --> 00:17:29,360
Und dann schauen wir uns an, wie wir Express-Express-Sitzungen

234
00:17:29,360 --> 00:17:35,121
innerhalb unserer Express-REST-API-Anwendung nutzen, an der wir bisher gearbeitet haben.

235
00:17:35,121 --> 00:17:40,109
( MUSIK)