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

2
00:00:04,614 --> 00:00:09,792
Wir hatten bereits einen vollwertigen REST-API-Server mit Express und

3
00:00:09,792 --> 00:00:12,026
MongoDB im Rahmen dieses Kurses entwickelt.

4
00:00:12,026 --> 00:00:16,881
Damit der Server sinnvoll mit unserem Kunden kommunizieren kann,

5
00:00:16,881 --> 00:00:21,892
werden wir einige kleinere Anpassungen vornehmen, damit er die richtige Art von Daten zurückgibt.

6
00:00:21,892 --> 00:00:26,063
Damit unsere Client-Implementierung effizienter

7
00:00:26,063 --> 00:00:29,370
mit den Daten arbeiten kann, die von unserer Serverseite zurückgegeben werden.

8
00:00:29,370 --> 00:00:30,427
Um dies zu tun,

9
00:00:30,427 --> 00:00:35,724
lassen Sie uns in dieser Übung an ein paar Anpassungen auf unserer Serverseite arbeiten.

10
00:00:37,478 --> 00:00:43,220
Gehen Sie zu unserem Server im Editor, bevor wir mit der Arbeit auf dem Server beginnen,

11
00:00:43,220 --> 00:00:48,497
würde ich vorschlagen, dass Sie alle Bilder herunterladen, die ich

12
00:00:48,497 --> 00:00:53,260
als ZIP-Datei in den Übungsressourcen namens images.zip bereitgestellt habe.

13
00:00:53,260 --> 00:00:56,530
Entpacken Sie die Datei und erhalten Sie dann alle Bilder von dort, und

14
00:00:56,530 --> 00:01:03,440
kopieren Sie diese Bilder in den Ordner für öffentliche Bilder auf unserem Server.

15
00:01:03,440 --> 00:01:08,980
So sehen Sie, dass ich

16
00:01:08,980 --> 00:01:10,580
hier bereits alle Bilder in meinen Public Images Ordner kopiert habe.

17
00:01:10,580 --> 00:01:15,120
Weil unser Server derjenige ist, der all diese Bilder für

18
00:01:15,120 --> 00:01:17,460
unsere Client-Anwendung bereitstellen wird.

19
00:01:17,460 --> 00:01:22,820
Als nächstes gehen wir zu den Cors und passen diese Whitelist an, hier.

20
00:01:22,820 --> 00:01:27,919
Also für unsere Angular-Client-Anwendung, wenn wir es

21
00:01:27,919 --> 00:01:33,571
mit dem Befehl ng serve starten, läuft es bei localhost: 4200.

22
00:01:33,571 --> 00:01:36,196
Alle Anfragen, die von unserer

23
00:01:36,196 --> 00:01:40,750
Angular-Anwendung an den Server kommen, tragen das als Ursprung dort.

24
00:01:40,750 --> 00:01:44,710
Deshalb werde ich das in meine Whitelist hinzufügen, so

25
00:01:44,710 --> 00:01:50,310
dass alle Probleme mit Cors automatisch behoben werden.

26
00:01:50,310 --> 00:01:54,848
Also gehen Sie in diese cors.js Datei,

27
00:01:54,848 --> 00:01:59,698
in meiner Whitelist, hier, lassen Sie mich in

28
00:01:59,698 --> 00:02:08,371
der http://localhost:, 4200 hinzufügen.

29
00:02:08,371 --> 00:02:12,503
Und das ist der Ursprung, von dem mein ganzer Angular-Client

30
00:02:12,503 --> 00:02:16,690
die Anfrage stammt, die an diesen Server kommt.

31
00:02:16,690 --> 00:02:22,020
Auf diese Weise werden meine Cors keine Probleme für den Angular Client verursachen.

32
00:02:22,020 --> 00:02:27,760
Als nächstes müssen wir einige der Routen aktualisieren, um

33
00:02:27,760 --> 00:02:32,760
die Abfrageparameter zu behandeln, und auch ein paar kleinere andere Anpassungen.

34
00:02:32,760 --> 00:02:35,905
Lassen Sie mich mit den promoRouter.js Dateien beginnen.

35
00:02:35,905 --> 00:02:39,760
Das ist also einfach aktualisiert zu werden.

36
00:02:39,760 --> 00:02:44,790
Also gehe ich zur Datei promoRouter.js, in der promOuter Datei, für

37
00:02:44,790 --> 00:02:47,960
die get Anfrage, die wir hier bekommen,

38
00:02:47,960 --> 00:02:57,256
anstatt promotions.Find mit einem leeren JavaScript

39
00:02:57,256 --> 00:03:02,470
zu tun, hier würde ich die req.query als Parameter für diese promotions.Finden Sie hier.

40
00:03:02,470 --> 00:03:07,650
Das Gleiche mit dem LeaderRouter auch, also lass mich zur Datei leaderRouter.js gehen.

41
00:03:07,650 --> 00:03:09,786
Und im LeaderRouter auch

42
00:03:09,786 --> 00:03:14,642
hier, wo Sie Leaders.Find mit dem leeren JavaScript-Objekt finden.

43
00:03:14,642 --> 00:03:18,423
Ersetzen Sie diese stattdessen durch diese req.query, so

44
00:03:18,423 --> 00:03:21,852
dass die Abfrageparameter übergeben werden.

45
00:03:21,852 --> 00:03:26,430
Dies ist also, wo wir in der Featured Spalte

46
00:03:26,430 --> 00:03:29,487
durch als Abfrageparameter übergeben werden.

47
00:03:29,487 --> 00:03:34,678
Nachdem wir diese beiden angepasst haben, lassen Sie uns nun an der Dish Route arbeiten,

48
00:03:34,678 --> 00:03:41,090
also gehen Sie zur Datei dishRouter.js, sogar im DishRouter, das gleiche Update hier.

49
00:03:41,090 --> 00:03:48,920
Also gehen Sie zu diesem Gerichte.Finden Sie in der get-Methode hier, ändern Sie das zu req.query.

50
00:03:48,920 --> 00:03:52,987
Damit wurde mein DishRouter-Update abgeschlossen.

51
00:03:52,987 --> 00:03:57,664
So haben wir nun den Promorouter, den ReaderRouter und

52
00:03:57,664 --> 00:04:02,784
den DishRouter aktualisiert, dann werden wir fortfahren, um diesen FavoriterOuter zu aktualisieren.

53
00:04:02,784 --> 00:04:07,519
Jetzt hätten Sie den bevorzugten Router als Teil Ihrer

54
00:04:07,519 --> 00:04:09,500
vierten Aufgabe implementiert.

55
00:04:09,500 --> 00:04:12,306
Jetzt im FavoritErouter werden Sie sehen, dass

56
00:04:12,306 --> 00:04:16,618
ich Ihnen für den FavoritErouter nicht den verbleibenden Parter zeige, weil

57
00:04:16,618 --> 00:04:19,437
Sie das als Teil Ihrer Zuweisung hätten tun sollen.

58
00:04:19,437 --> 00:04:22,925
Lassen Sie mich zuerst Ihre Aufmerksamkeit auf die get-Methode für

59
00:04:22,925 --> 00:04:26,422
die FavoritRouter.route („/:dishid') lenken.

60
00:04:26,422 --> 00:04:31,161
Jetzt werde ich diese Get-Methode verwenden,

61
00:04:31,161 --> 00:04:35,653
um sicherzustellen, dass das spezifische Gericht mit

62
00:04:35,653 --> 00:04:40,292
einer DishiD bereits ein Favorit für den Benutzer ist.

63
00:04:40,292 --> 00:04:44,413
Anstatt also einfach die GET-Operation nicht unterstützt

64
00:04:44,413 --> 00:04:48,879
zu sagen, werde ich nur das Vorhandensein dieser Get-Operation nutzen.

65
00:04:48,879 --> 00:04:52,574
Und dann werden wir sagen,

66
00:04:52,574 --> 00:04:56,684
Favorites.Findone.

67
00:04:56,684 --> 00:04:59,843
Und ich werde sagen,

68
00:04:59,843 --> 00:05:04,952
Benutzer: req.user.id.

69
00:05:04,952 --> 00:05:10,194
So finden wir die Favoriten für diesen bestimmten Benutzer.

70
00:05:10,194 --> 00:05:20,166
Und dann werden wir sagen,. Dann, Favoriten.

71
00:05:26,483 --> 00:05:32,913
Und, fangen ((err),

72
00:05:35,757 --> 00:05:40,160
next (err)).

73
00:05:40,160 --> 00:05:45,638
Und dann ähnlich hier werden wir den Fehler hier hinzufügen.

74
00:05:48,689 --> 00:05:50,239
Weiter (äh)), hier.

75
00:05:50,239 --> 00:05:55,689
Also in diesem. dann, wenn wir die Favoriten bekommen,

76
00:05:55,689 --> 00:06:00,290
dann werden wir überprüfen, ob (! Favoriten).

77
00:06:00,290 --> 00:06:04,500
Also, wenn es für diesen Benutzer keine Favoriten gibt,

78
00:06:04,500 --> 00:06:08,770
dann gibt es offensichtlich das Gericht, nach dem wir suchen, nicht.

79
00:06:08,770 --> 00:06:18,604
Also werden wir zurückkehren, Res.StatusCode, 200.

80
00:06:22,232 --> 00:06:29,488
setHeader ('Content-Type

81
00:06:29,488 --> 00:06:34,436
'' 'Anwendung/json').

82
00:06:34,436 --> 00:06:36,237
Und dann werden wir zurückkehren,

83
00:06:42,997 --> 00:06:51,490
Sprichwort, „existiert“: falsch.

84
00:06:51,490 --> 00:06:56,891
Was wir hier angeben, ist, dass, wenn das Get

85
00:06:56,891 --> 00:07:02,771
zu diesem Endpunkt mit einer DishID gemacht wird, dieses Existes-Flag hier

86
00:07:02,771 --> 00:07:07,826
auf true gesetzt wird, wenn dieses Gericht Teil meiner Favoriten ist.

87
00:07:07,826 --> 00:07:13,008
Wenn dieses Gericht nicht Teil meiner Favoriten ist, setze ich das Existes-Flag auf false.

88
00:07:13,008 --> 00:07:16,687
Also hier sehen Sie, dass da ich keine Favoriten habe, also

89
00:07:16,687 --> 00:07:20,008
existieren sollte automatisch falsch an dieser Stelle sein.

90
00:07:20,008 --> 00:07:26,780
Also sagen wir „existiert“: false, und dann werden wir die Favoriten hier zurückgeben.

91
00:07:28,950 --> 00:07:31,237
Nun, offensichtlich

92
00:07:31,237 --> 00:07:35,225
wären die Favoriten in diesem Fall an dieser Stelle null, sonst.

93
00:07:39,097 --> 00:07:42,779
Was bedeutet, dass Favoriten nicht null sind, also sagen wir, wenn,

94
00:07:45,218 --> 00:07:52,688
(favorites.dishs.indexOf),

95
00:07:52,688 --> 00:07:58,011
also werden wir nach req.params suchen.

96
00:08:00,046 --> 00:08:02,620
Dishid, also werden wir das durchsuchen.

97
00:08:02,620 --> 00:08:09,632
Favorites.Dishes.array, um zu sehen, ob Gericht dort existiert.

98
00:08:09,632 --> 00:08:15,410
Und wenn es nicht existiert, wird dies hier natürlich einen negativen Index zurückgeben.

99
00:08:15,410 --> 00:08:20,200
Also in diesem Fall werde ich auch genau das gleiche wie hier zurückgeben.

100
00:08:20,200 --> 00:08:22,291
Wenn es also einen negativen Index zurückgibt,

101
00:08:22,291 --> 00:08:26,990
dann bedeutet das, dass, obwohl dieser bestimmte Benutzer einen Mittelfavorit hat.

102
00:08:26,990 --> 00:08:31,464
Dieses spezifische Gericht gibt es nicht in der Liste sein oder

103
00:08:31,464 --> 00:08:36,987
ihr Favorit, also ist es, warum es gibt hier falsch zurück.

104
00:08:36,987 --> 00:08:45,119
Nun, sonst bedeutet das, dass das Gericht in der Liste der Favoriten existieren.

105
00:08:45,119 --> 00:08:51,352
Also in diesem Fall werde ich Statuscode zurückgeben 200 existiert ist wahr.

106
00:08:51,352 --> 00:08:57,144
Auf diese Weise, wenn der Benutzer eine get Operation an

107
00:08:57,144 --> 00:09:02,408
diesem Endpunkt mit der /favorite/dishid ausführt.

108
00:09:02,408 --> 00:09:07,265
Wo die disHID als Parameter hier angegeben wird.

109
00:09:07,265 --> 00:09:09,821
Als Records Parameter hier,

110
00:09:09,821 --> 00:09:15,226
dann werden wir überprüfen, ob dieses Gericht in den Favoriten existiert.

111
00:09:15,226 --> 00:09:19,983
Wenn keiner der Favoriten für diesen Benutzer vorhanden ist, geben wir eine existierende false zurück.

112
00:09:19,983 --> 00:09:22,138
In ähnlicher Weise, wenn die Favoriten vorhanden sind,

113
00:09:22,138 --> 00:09:27,000
aber dieses bestimmte Gericht nicht in den Favoriten existiert, wird es eine false zurückgeben.

114
00:09:27,000 --> 00:09:28,705
Andernfalls wird es ein true zurückgeben.

115
00:09:28,705 --> 00:09:33,890
Also diese existierende Flagge kann von meinem Client verwendet werden,

116
00:09:33,890 --> 00:09:41,997
um zu überprüfen, ob dieses Gericht Teil der Liste der Lieblingsgerichte für diesen Benutzer ist oder nicht.

117
00:09:41,997 --> 00:09:48,624
Schließlich werden wir die Datei users.js aktualisieren.

118
00:09:48,624 --> 00:09:53,284
Jetzt in der Datei users.js müssen wir in

119
00:09:53,284 --> 00:09:58,204
einem anderen Feld router.options hinzufügen, da

120
00:09:58,204 --> 00:10:03,769
manchmal eine Post-Anfrage, wie Sie mit dem Login gesehen

121
00:10:03,769 --> 00:10:10,760
haben, werden wir zuerst die Optionen senden, um zu überprüfen, vor allem mit Autos,

122
00:10:10,760 --> 00:10:16,140
ob die Post-Anfrage erlaubt ist.

123
00:10:16,140 --> 00:10:23,156
Deshalb überprüfen sie Autos, Autos mit Optionen hier und dann.

124
00:10:26,156 --> 00:10:27,915
Wir werden einfach

125
00:10:34,203 --> 00:10:39,938
eine Statusmeldung von 200 als Antwort darauf zurückgeben.

126
00:10:39,938 --> 00:10:44,624
Also für jeden Endpunkt unter Benutzern, wenn wir

127
00:10:44,624 --> 00:10:50,183
die Optionen erhalten haben, wird einfach einen Status zurückgeben 200 hier.

128
00:10:50,183 --> 00:10:57,417
Jetzt die Login-Funktion, die wir früher implementiert hatten.

129
00:10:57,417 --> 00:11:02,782
Wir haben hier einfach passport.authenticate ('local') gemacht und

130
00:11:02,782 --> 00:11:06,600
dann überprüfen wir hier die restlichen Werte.

131
00:11:06,600 --> 00:11:11,006
Jetzt gibt diese passport.authenticate ('local'), wenn der Benutzer nicht

132
00:11:11,006 --> 00:11:15,221
authentifiziert wird, einfach eine Unautorisierte in der Antwortnachricht zurück.

133
00:11:15,221 --> 00:11:18,212
Nun, das ist möglicherweise nicht sehr sinnvoll für

134
00:11:18,212 --> 00:11:21,868
die Client-Seite, um diese Informationen anzuzeigen.

135
00:11:21,868 --> 00:11:27,245
Deshalb werden wir diese Router-Post-Login-Methode

136
00:11:27,245 --> 00:11:35,158
so verbessern, dass die Authentifizierung aussagekräftigere Informationen an diesem Teil zurückgibt.

137
00:11:35,158 --> 00:11:39,831
Also, um das zu tun, werden wir nicht tun, dass der Pass

138
00:11:39,831 --> 00:11:43,120
hier drin authentifiziert wird.

139
00:11:43,120 --> 00:11:47,180
Stattdessen werden wir nehmen, also lassen Sie mich das von dort entfernen,

140
00:11:47,180 --> 00:11:52,410
und dann werden Sie sehen, wie ich den Routerpost hier aktualisieren werde.

141
00:11:52,410 --> 00:11:56,520
Also werden wir CarsWithOptions sehen.

142
00:11:56,520 --> 00:12:03,806
Und dann werden wir die req, res und das nächste hier einschließen.

143
00:12:03,806 --> 00:12:08,216
Und innerhalb der req, res, und

144
00:12:08,216 --> 00:12:14,227
weiter hier, passport.authenticate,

145
00:12:17,271 --> 00:12:22,035
Wir nennen dies mit „local'.

146
00:12:22,035 --> 00:12:27,041
Nun, wenn wir dies mit lokalen aufrufen, wenn ein

147
00:12:27,041 --> 00:12:34,607
Authentifizierungsfehler auftritt, kann die passport.authenticate gemacht werden, um den Fehlerwert zurückzugeben,

148
00:12:34,607 --> 00:12:39,519
und es wird auch den Benutzer zurückgeben, wenn kein Fehler vorliegt.

149
00:12:39,519 --> 00:12:42,283
Und es könnte Parameter namens info,

150
00:12:42,283 --> 00:12:47,643
die zusätzliche Informationen enthält, die an den Benutzer zurückgegeben werden könnten.

151
00:12:47,643 --> 00:12:51,714
Dieser Fehler wird zurückgegeben, wenn ein echter Fehler auftritt,

152
00:12:51,714 --> 00:12:53,590
der in der möglichen Authentifizierung auftritt.

153
00:12:53,590 --> 00:12:58,995
Wenn jedoch die Benutzerinformationen an passport.authenticate gesendet werden,

154
00:12:58,995 --> 00:13:03,945
der Benutzer jedoch nicht existiert, wird dies nicht als Fehler gezählt.

155
00:13:03,945 --> 00:13:07,828
Stattdessen wird es als Benutzer nicht existiert gezählt.

156
00:13:07,828 --> 00:13:12,825
Und diese Information wird in dem Info-Objekt zurückgegeben, das hereinkommt.

157
00:13:12,825 --> 00:13:16,793
Daher wird der Fehler zurückgegeben, wenn ein echter Fehler auftritt, der während

158
00:13:16,793 --> 00:13:18,405
des Authentifizierungsprozesses auftritt.

159
00:13:18,405 --> 00:13:23,995
Aber die Info, sie enthalten Informationen, wenn der Benutzer nicht existiert und daher

160
00:13:23,995 --> 00:13:30,102
die passport.authenticate eine Nachricht zurückgibt, die besagt, dass der Benutzer nicht

161
00:13:30,102 --> 00:13:35,780
existiert oder entweder der Benutzername falsch ist oder das Kennwort falsch ist.

162
00:13:35,780 --> 00:13:40,415
Und so weiter, damit Informationen in der Info-Nachricht weitergegeben werden.

163
00:13:40,415 --> 00:13:44,569
Nun werden wir sehen, wie das für uns nützlich ist, wenn wir uns ein

164
00:13:44,569 --> 00:13:45,990
wenig später auf die Client-Seite schauen.

165
00:13:45,990 --> 00:13:48,070
In dieser Situation

166
00:13:49,530 --> 00:13:55,110
werden wir das wie folgt behandeln.

167
00:13:55,110 --> 00:14:00,510
Und nicht nur, dass, wenn wir nennen diesen Pass authentifizieren,

168
00:14:00,510 --> 00:14:04,976
wir müssen auch in einem übergeben (req, res,

169
00:14:04,976 --> 00:14:08,550
next) wie diese drei Parameter-Streifen.

170
00:14:08,550 --> 00:14:10,320
Das ist also die Struktur.

171
00:14:10,320 --> 00:14:13,558
Wenn Sie Pass-Authentifizierung anrufen müssen,

172
00:14:13,558 --> 00:14:18,798
erwarten Sie, dass es Ihnen Informationen wie diese als Rückrufmethode hier zurückgibt.

173
00:14:18,798 --> 00:14:24,072
Also müssen Sie auch diese Req liefern, res nächstes gleich dort.

174
00:14:24,072 --> 00:14:25,720
Nun, wenn das passiert.

175
00:14:25,720 --> 00:14:30,206
Also werden wir sagen, wenn (äh).

176
00:14:30,206 --> 00:14:34,163
Wenn also ein Fehler auftritt,

177
00:14:34,163 --> 00:14:39,781
sagen wir return next (err) und lassen Sie sich dann den

178
00:14:39,781 --> 00:14:45,028
Fehler-Handler unseres Express-Routers darum kümmern.

179
00:14:45,028 --> 00:14:48,365
Jetzt werden wir andere Situationen betrachten.

180
00:14:48,365 --> 00:14:53,484
Wenn (! Benutzer), also wenn wir diesen Punkt erreicht haben, bedeutet das, dass es

181
00:14:53,484 --> 00:14:59,232
kein Fehler war, der aufgetreten ist, sondern vielleicht konnte der Benutzer nicht gefunden werden.

182
00:14:59,232 --> 00:15:04,860
Wenn der Benutzer nicht gefunden wird, wird der Benutzer hier in diesem Fall auf null gesetzt.

183
00:15:04,860 --> 00:15:10,088
Also, in dieser Situation, wenn der Benutzer nicht existiert,

184
00:15:10,088 --> 00:15:17,068
müssen wir in der Lage sein, Informationen zurück an die Serverseite zu übergeben.

185
00:15:17,068 --> 00:15:22,895
Was wir also tun werden, ist, dass wir diese Informationen in diesem Format übergeben werden,

186
00:15:22,895 --> 00:15:26,576
also werde ich das hier ausschneiden, und

187
00:15:26,576 --> 00:15:30,491
dann fügen Sie es hier ein und dann werden wir es bearbeiten.

188
00:15:30,491 --> 00:15:36,748
Wenn der Benutzer null ist, dann werden wir einen StatusCode

189
00:15:36,748 --> 00:15:41,509
von 401 zurücksenden, was nicht autorisiert bedeutet, und

190
00:15:41,509 --> 00:15:47,640
dann senden wir Informationen Erfolg, false zurück.

191
00:15:47,640 --> 00:15:54,340
Und dann geben wir das Token nicht zurück, wir geben die Statusmeldung zurück.

192
00:15:54,340 --> 00:16:02,501
Also hier sagen wir Login, Erfolglos.

193
00:16:02,501 --> 00:16:07,870
Und dann wird die dritte Information diese Information übergeben,

194
00:16:07,870 --> 00:16:13,238
das Objekt, das wir hier als dritter Teil dieser

195
00:16:13,238 --> 00:16:19,231
Antwortnachricht erhalten haben, die wir von unserem Server hier zurücksenden.

196
00:16:19,231 --> 00:16:22,496
Das Erfolgsflag wird also auf false zurückgesetzt.

197
00:16:22,496 --> 00:16:27,145
Der Status wird Login fehlgeschlagen gesetzt und die Fehlerinformationen,

198
00:16:27,145 --> 00:16:30,235
die in der Info übergeben werden, werden zurückgegeben.

199
00:16:30,235 --> 00:16:34,788
Beachten Sie nun, dass diese Situation auftritt, wenn entweder der Benutzername und

200
00:16:34,788 --> 00:16:36,789
das Passwort falsch sind.

201
00:16:36,789 --> 00:16:42,516
Und so ist dies kein Fehler, im Fehlersinn, aber die Tatsache, dass die Authentifizierung

202
00:16:42,516 --> 00:16:47,505
weder den Benutzer noch das Passwort des Benutzers finden konnte, ist falsch.

203
00:16:47,505 --> 00:16:51,545
So werden die Informationen in den Zufluss codiert, der hereinkommt, und

204
00:16:51,545 --> 00:16:58,227
damit ich als Fehler an meine Client-Seite weitergebe.

205
00:16:58,227 --> 00:17:02,633
Andernfalls wird Teil

206
00:17:02,633 --> 00:17:08,810
als Req.login behandelt.

207
00:17:08,810 --> 00:17:10,700
Wenn dies also erfolgreich ist, fügt

208
00:17:10,700 --> 00:17:16,200
die passport.authenticate dem Benutzer diese Methode namens Req.login hinzu.

209
00:17:16,200 --> 00:17:21,400
Also an dieser Stelle werden wir nur das Benutzerobjekt übergeben, das wir erhalten haben.

210
00:17:21,400 --> 00:17:26,398
Also, hier, wenn wir diesen Punkt erreicht haben,

211
00:17:26,398 --> 00:17:32,572
dann bedeutet das, dass das Benutzerobjekt nicht null ist und

212
00:17:32,572 --> 00:17:37,717
auch kein Fehler aufgetreten ist, so dass

213
00:17:37,717 --> 00:17:43,304
der Benutzer eingeloggt werden kann und so sagen wir irr.

214
00:17:43,304 --> 00:17:44,995
So wird es versuchen, den Benutzer anzumelden.

215
00:17:44,995 --> 00:17:47,231
Also werden wir sagen, wenn irrtümlich.

216
00:17:51,210 --> 00:17:58,260
Und dann werden wir die gleiche Art von Fehlerinformationen zurückgeben, die wir hier gemacht haben.

217
00:17:59,450 --> 00:18:02,317
Also in diesem Fall, wenn der Fehler.

218
00:18:06,077 --> 00:18:11,757
Wenn Fehler, dann werden wir den Statuscode 401 zurückgeben und

219
00:18:11,757 --> 00:18:18,970
wir sagen, dass Erfolg falsch ist und der Status Login fehlgeschlagen ist.

220
00:18:18,970 --> 00:18:24,359
Und dann die Fehlerinformationen, die

221
00:18:24,359 --> 00:18:29,539
wir übergeben werden, da anstelle von

222
00:18:29,539 --> 00:18:36,810
Informationen, die wir übergeben werden, konnte sich nicht in Benutzer anmelden.

223
00:18:36,810 --> 00:18:42,580
Das ist also die Nachricht, die hier zurückgegeben wird, wenn der Fehler auftritt.

224
00:18:42,580 --> 00:18:46,195
Sonst wären wir hier unten.

225
00:18:46,195 --> 00:18:53,157
Und so würden wir an dieser Stelle in der Lage sein, das Token zu generieren.

226
00:18:53,157 --> 00:18:57,594
Also, wenn wir bis zu diesem Punkt erreicht haben, bedeutet das, dass der Benutzer sich

227
00:18:57,594 --> 00:19:01,892
erfolgreich angemeldet hat und so können wir jetzt das Token generieren.

228
00:19:01,892 --> 00:19:07,009
Also werden wir das Token basierend auf der Benutzer-ID generieren und

229
00:19:07,009 --> 00:19:11,794
dann werden wir dieses Token an den Benutzer zurückgeben.

230
00:19:11,794 --> 00:19:15,462
Also hier werden wir var Token sagen.

231
00:19:15,462 --> 00:19:22,789
Und dann können wir res.StatusCode = 200 sagen, und dann res.json (Erfolg) ist wahr,

232
00:19:22,789 --> 00:19:26,999
was bedeutet, dass der Benutzer erfolgreich angemeldet ist.

233
00:19:26,999 --> 00:19:31,842
Und so wäre der Status Login Erfolgreich, und

234
00:19:31,842 --> 00:19:39,900
dann der dritte Teil anstelle des Fehlers werde ich das Token zurück an den Benutzer übergeben.

235
00:19:39,900 --> 00:19:45,590
Also sagen wir Token, Token,

236
00:19:45,590 --> 00:19:50,390
dieses Token, das wir gerade früher erhalten haben, so dass to-Token

237
00:19:50,390 --> 00:19:54,600
als Token-Eigenschaft der rip light Nachricht übergeben wird.

238
00:19:54,600 --> 00:19:57,910
Beachten Sie hier, dass diese Achse auf true gesetzt ist.

239
00:19:57,910 --> 00:20:01,890
Das bedeutet, dass sich der Benutzer erfolgreich angemeldet hat.

240
00:20:01,890 --> 00:20:05,660
Und so kann der Benutzer an dieser Stelle vorwärts gehen.

241
00:20:05,660 --> 00:20:13,667
Und das muss innerhalb der Req.login hier getan werden.

242
00:20:13,667 --> 00:20:20,640
Also an dieser Stelle werden wir die Req.login schließen.

243
00:20:20,640 --> 00:20:27,570
Beachten Sie also, dass dies in diesem Req.login hier ist.

244
00:20:27,570 --> 00:20:30,830
Also da drinnen werden wir diese drei zurückgeben.

245
00:20:30,830 --> 00:20:33,800
Also lassen Sie mich einfach drei Zeilen einrücken.

246
00:20:35,830 --> 00:20:42,490
Und so würden wir mit der Benutzeranmeldung umgehen.

247
00:20:42,490 --> 00:20:45,850
Also nochmals, diesen Code noch einmal zu überprüfen.

248
00:20:45,850 --> 00:20:47,740
Also werden wir Router-Post tun, aber

249
00:20:47,740 --> 00:20:52,490
statt Pass authentifizieren genau dort, werden wir sagen, req, res,

250
00:20:52,490 --> 00:20:57,970
nächste und dann innen hier werden wir einen Pass zu tun.authenticate für die lokale.

251
00:20:57,970 --> 00:21:02,930
Und diese Authentifizierung wird zurückübergeben, so dass wir eine Callback-Funktion liefern können.

252
00:21:02,930 --> 00:21:06,810
Und diese Callback-Funktion gibt entweder den Fehler, den Benutzer oder

253
00:21:06,810 --> 00:21:08,370
die Info hier zurück.

254
00:21:08,370 --> 00:21:13,220
Und wenn es einen Fehler verursacht, erlauben wir dem Express-Fehler-Handler,

255
00:21:13,220 --> 00:21:14,560
sich darum zu kümmern.

256
00:21:14,560 --> 00:21:20,580
Wenn der Benutzer null ist, bedeutet dies, dass die Benutzeranmeldung fehlgeschlagen war,

257
00:21:20,580 --> 00:21:25,090
und der Grund dafür wird in der Info sein, so dass es als

258
00:21:25,090 --> 00:21:30,660
Infofehler in der Planmeldung hier zurückgegeben wird.

259
00:21:30,660 --> 00:21:37,190
Wenn wir zu diesem Punkt kommen, dann wird der Benutzer erfolgreich verifiziert.

260
00:21:37,190 --> 00:21:38,898
Also dann werden wir den Benutzer einloggen.

261
00:21:38,898 --> 00:21:43,850
So wird die passport.authenticate in dieser Methode namens Login zur

262
00:21:43,850 --> 00:21:51,090
Anforderungsnachricht hinzufügen, so dass wir die Anmeldung mit dem Benutzer aufrufen können und

263
00:21:51,090 --> 00:21:56,760
wenn dies einen Fehler zurückgibt, dann werden wir den Fehler hier entsprechend zurückgeben.

264
00:21:56,760 --> 00:22:01,400
Wenn nicht, hätten wir den Punkt erreicht, an dem der Benutzer erfolgreich

265
00:22:01,400 --> 00:22:06,560
authentifiziert wurde, damit er das JSON-Web-Token hier generieren und das

266
00:22:06,560 --> 00:22:12,020
JSON-Web-Token an den Benutzer zurückgeben kann, um zu bestätigen, dass der Benutzer erfolgreich angemeldet ist.

267
00:22:12,020 --> 00:22:15,190
Das ist also die Reihe von Schritten, die wir hier verwenden werden.

268
00:22:15,190 --> 00:22:19,910
Jetzt ist der Grund, warum ich eine aufwändigere Art und Weise mache, dass ich

269
00:22:19,910 --> 00:22:24,760
zwischen der Situation unterscheiden möchte, in der ein echter Fehler während

270
00:22:24,760 --> 00:22:30,700
des Anwendungsprozesses auftritt, im Gegensatz zu der Situation, in der der Benutzername ungültig ist

271
00:22:30,700 --> 00:22:32,830
oder das Passwort ungültig ist.

272
00:22:32,830 --> 00:22:37,713
Diese beiden Fälle werden also von dieser Situation behandelt, in der

273
00:22:37,713 --> 00:22:40,129
die Informationen zu uns zurückführen werden.

274
00:22:40,129 --> 00:22:44,551
Das ist also kein Fehler, aber das ist eine Situation, in

275
00:22:44,551 --> 00:22:49,440
der der Benutzer kein gültiger Benutzer ist oder das Passwort des Benutzers ungültig ist.

276
00:22:49,440 --> 00:22:54,880
So werden sie mit dem Anmeldeprozess des Benutzers umgehen.

277
00:22:54,880 --> 00:22:59,666
Darüber hinaus werde ich hier eine weitere Methode namens

278
00:23:05,730 --> 00:23:08,832
checkJWToken hinzufügen.

279
00:23:08,832 --> 00:23:12,831
Es ist durchaus möglich, dass, während der Client sich angemeldet und

280
00:23:12,831 --> 00:23:18,229
das JSON-Web-Token erhalten hat, irgendwann später das JSON-Web-Token ablaufen kann.

281
00:23:18,229 --> 00:23:23,776
Und wenn der Benutzer versucht, von der Clientseite mit einem abgelaufenen Token

282
00:23:23,776 --> 00:23:29,159
auf den Server zuzugreifen, kann der Server den Benutzer nicht authentifizieren.

283
00:23:29,159 --> 00:23:34,024
In regelmäßigen Abständen möchten wir daher möglicherweise eine Kreuzprüfung durchführen, um sicherzustellen, dass das

284
00:23:34,024 --> 00:23:35,733
JSON-Web-Token immer noch gültig ist.

285
00:23:35,733 --> 00:23:41,180
Das ist der Grund, warum ich einen anderen Endpunkt namens

286
00:23:41,180 --> 00:23:46,131
checkJWTToken einschließe, also wenn Sie einen get to checkJWTToken machen.

287
00:23:46,131 --> 00:23:50,927
Indem Sie das Token in den Autorisierungsheader

288
00:23:50,927 --> 00:23:55,926
aufnehmen, gibt dieser Aufruf einen true oder false zurück, um Ihnen anzuzeigen,

289
00:23:55,926 --> 00:24:00,125
ob das JSON-Web-Token noch gültig ist oder nicht.

290
00:24:00,125 --> 00:24:04,430
Wenn es ungültig ist, kann die Clientseite bei

291
00:24:04,430 --> 00:24:09,710
Bedarf eine weitere Anmeldung für den Benutzer initiieren, um ein neues JSON-Web-Token zu erhalten.

292
00:24:09,710 --> 00:24:15,470
Um dies zu tun, sagen wir cors, corsWithOptions und,

293
00:24:19,500 --> 00:24:23,760
req, res, hier, wie erwartet.

294
00:24:25,510 --> 00:24:28,029
Und hier werden wir sagen,

295
00:24:31,852 --> 00:24:40,983
passport.authenticate ('jwt',

296
00:24:42,356 --> 00:24:49,886
Und, {session: false}).

297
00:24:54,050 --> 00:24:59,322
Und das würde irr, user, info zurückgeben.

298
00:25:03,010 --> 00:25:07,005
Also erinnern Sie sich, wie wir den Passport-Authentifikator früher verwendet haben.

299
00:25:07,005 --> 00:25:11,050
Also fällt die JWT-Sitzung hier.

300
00:25:11,050 --> 00:25:14,759
Also früher hier sagen wir, passport.authentifizieren lokale.

301
00:25:14,759 --> 00:25:17,039
Dies ist also für die lokale Authentifizierung.

302
00:25:17,039 --> 00:25:21,038
Dies ist also für die JSON-Web-Token-Authentifizierung.

303
00:25:21,038 --> 00:25:26,303
Also, wenn wir das aufrufen, da dies das JSON-Web-Token überprüfen wird,

304
00:25:26,303 --> 00:25:33,820
also werde ich sagen, wenn (err), als nächstes zurückgeben (err).

305
00:25:33,820 --> 00:25:38,540
Und dann lassen Sie sich der Express-Fehlerbehandler um diese Situation kümmern.

306
00:25:38,540 --> 00:25:42,895
Und dann werden wir sagen, wenn (! Benutzer),

307
00:25:47,340 --> 00:25:53,395
Wenn der Benutzer nicht existiert, dann ähnlich, sonst.

308
00:25:53,395 --> 00:25:58,850
Was bedeutet, dass, wenn das Benutzerobjekt aus dem JSON-Web-Token gefunden und

309
00:25:58,850 --> 00:26:04,764
dann auf den req.user geladen wurde, bedeutet das, dass der Benutzer ein gültiger Benutzer ist.

310
00:26:04,764 --> 00:26:06,990
Und so kann erlaubt werden, vorwärts zu gehen.

311
00:26:06,990 --> 00:26:13,770
Andernfalls werden wir sagen, dass der Benutzer nicht existiert.

312
00:26:13,770 --> 00:26:18,480
Wir müssen also folgern, dass das JSON-Web-Token abgelaufen ist.

313
00:26:18,480 --> 00:26:24,495
Also an diesem Punkt senden wir ein res mit dem Statuscode von,

314
00:26:29,070 --> 00:26:31,580
401, also nicht autorisiert.

315
00:26:33,847 --> 00:26:40,570
setHeader (, 'Content-Type',

316
00:26:42,865 --> 00:26:45,940
'application/json').

317
00:26:45,940 --> 00:26:52,243
Und dann werden wir res,

318
00:26:54,894 --> 00:27:00,970
.json zurückgeben, wir sagen, {status:,

319
00:27:04,165 --> 00:27:07,131
'JWT ungültig! '.

320
00:27:07,131 --> 00:27:15,242
Und dann werden Wir eine Flagge namens Erfolg zurückgeben: false.

321
00:27:15,242 --> 00:27:20,624
Und dann, Wir werden die Informationen zurückgeben,

322
00:27:20,624 --> 00:27:26,890
die wir erhalten, wenn der Benutzer nicht als Fehler an dieser Stelle authentifiziert.

323
00:27:30,450 --> 00:27:36,219
Andernfalls bedeutet das, dass wir diesen Punkt erreichen, wenn der Benutzer ein gültiger Benutzer ist.

324
00:27:36,219 --> 00:27:40,921
Also lassen Sie mich in diesem Fall einfach diesen Code hier kopieren,

325
00:27:40,921 --> 00:27:45,392
wir werden einen Statuscode von 200 senden, und

326
00:27:45,392 --> 00:27:48,727
dann wird der res.json JWT senden,

327
00:27:51,140 --> 00:27:55,050
gültig! , und Erfolg wird wahr sein.

328
00:27:56,550 --> 00:28:03,290
Und im dritten Teil werden wir die Informationen des Benutzers senden.

329
00:28:03,290 --> 00:28:07,776
Wenn dieser Endpunkt

330
00:28:07,776 --> 00:28:12,710
mit der get-Methode aufgerufen wird, überprüft dies, ob das Token gültig ist oder nicht.

331
00:28:12,710 --> 00:28:15,580
Wenn das Token gültig ist, erhalten Sie diese Antwort.

332
00:28:15,580 --> 00:28:17,311
Und aus dem Erfolgsflag in der Antwort

333
00:28:17,311 --> 00:28:20,050
können Sie überprüfen, ob das JSON-Web-Token gültig ist oder nicht.

334
00:28:20,050 --> 00:28:24,010
Und das ist auf der Client-Seite nützlich.

335
00:28:24,010 --> 00:28:30,012
Nun

336
00:28:30,012 --> 00:28:37,720
muss dieser Pass hier, passport.authenticate hier, mit req und res als die beiden Parameter hier geliefert werden.

337
00:28:37,720 --> 00:28:41,320
So nennen wir diesen passport.authenticate.

338
00:28:41,320 --> 00:28:45,060
Beachten Sie, dass, wenn Sie passport.authenticate aufrufen und

339
00:28:45,060 --> 00:28:49,917
diese Callback-Funktion hier erwarten, Sie diesen Punkt, req,

340
00:28:49,917 --> 00:28:53,973
.res, an diesen passport.authenticate und dann wieder hier anhängen müssen.

341
00:28:53,973 --> 00:28:57,915
Damit haben wir alles auf der Serverseite aktualisiert.

342
00:28:57,915 --> 00:29:01,900
Lassen Sie uns also alle Änderungen auf der Serverseite speichern.

343
00:29:01,900 --> 00:29:05,400
Jetzt ist unser Server bereit,

344
00:29:05,400 --> 00:29:10,680
die eingehenden Anfragen von unserem Angular-Client zu bearbeiten.

345
00:29:10,680 --> 00:29:13,120
Damit schließen wir diese Übung ab.

346
00:29:13,120 --> 00:29:18,010
In dieser Übung haben wir nun unseren Express-Server vorbereitet, um

347
00:29:18,010 --> 00:29:22,930
eingehende Anfragen von unserem Angular-Client zu bearbeiten.

348
00:29:22,930 --> 00:29:26,890
In der nächsten Übung werden wir uns den Angular-Client genauer ansehen, um zu

349
00:29:26,890 --> 00:29:32,350
verstehen, wie er mit diesem zusätzlichen Server kommuniziert.

350
00:29:32,350 --> 00:29:37,881
Dies ist ein guter Zeitpunkt für Sie, ein Git-Commit mit der Nachricht zu machen, indem Sie

351
00:29:37,881 --> 00:29:40,932
Client und Server integrieren.

352
00:29:40,932 --> 00:29:44,825
( MUSIK)