1
00:00:03,890 --> 00:00:11,670
Nun, da wir die tokenbasierte Authentifizierung mit den JSON-Web-Token

2
00:00:11,670 --> 00:00:16,035
verstanden haben und auch die Vorteile der Verwendung dieses Ansatzes verstanden haben.

3
00:00:16,035 --> 00:00:22,185
Die Tatsache, dass wir jetzt einen Rest-API-basierten Server erstellen,

4
00:00:22,185 --> 00:00:24,420
bedeutet in diesem Kurs, dass

5
00:00:24,420 --> 00:00:27,585
die JSON Web Token basierte Authentifizierung

6
00:00:27,585 --> 00:00:31,410
am besten für diesen Server geeignet ist, den wir erstellen.

7
00:00:31,410 --> 00:00:40,585
Lassen Sie uns also unseren Rest API-Server aktualisieren, um JSON-Web-Token in dieser Übung zu verwenden. Um mit

8
00:00:40,585 --> 00:00:45,755
der Aktualisierung des Servers an Ihrem Terminal zu beginnen,

9
00:00:45,755 --> 00:00:51,935
installieren wir zuerst das JSON Web Token und das Passport JWT Node Modul.

10
00:00:51,935 --> 00:00:56,445
Also, an der Eingabeaufforderung geben Sie npm, installieren,

11
00:00:56,445 --> 00:01:05,640
Pass JWT JSON Web Token und minus sparen.

12
00:01:05,640 --> 00:01:15,435
Wie Sie sehen können, verwende ich JSON Web Token 8.3.0 und Pass JWT 4.0.0 in diesem Kurs.

13
00:01:15,435 --> 00:01:23,180
Nun, da wir die Installation abgeschlossen haben, lassen Sie uns fortfahren und unseren Express-Server aktualisieren.

14
00:01:23,180 --> 00:01:25,700
Gehen wir jetzt zu unserem Code,

15
00:01:25,700 --> 00:01:30,289
lassen Sie uns eine Datei namens

16
00:01:30,289 --> 00:01:36,335
conflict.js im Stammordner unseres Projekts hinzufügen.

17
00:01:36,335 --> 00:01:39,455
Nun, diese conflict.js Datei werde ich es verwenden,

18
00:01:39,455 --> 00:01:43,220
um einige Konfigurationsinformationen für unseren Server zu speichern.

19
00:01:43,220 --> 00:01:53,600
Nun, dies ist eine Möglichkeit, die gesamte Konfiguration für unseren Server zu zentralisieren.

20
00:01:53,600 --> 00:01:59,825
Lassen Sie mich in dieser Datei conflict.js ein JSON-Objekt hier exportieren.

21
00:01:59,825 --> 00:02:02,490
Also sagen wir, SecretKey,

22
00:02:08,510 --> 00:02:11,550
und hier

23
00:02:19,450 --> 00:02:28,705
werde ich den geheimen Schlüssel angeben, den ich zum Signieren meines JSON-Web-Token verwenden werde,

24
00:02:28,705 --> 00:02:36,700
und lassen Sie mich hier auch eine Mongo-URL angeben,

25
00:02:36,700 --> 00:02:41,275
die die URL für

26
00:02:41,275 --> 00:02:51,710
meinen MongoDB-Server localhost 27017 sein wird.

27
00:02:52,200 --> 00:02:55,060
Sobald wir das abgeschlossen haben,

28
00:02:55,060 --> 00:02:59,260
dann werden wir zu authenticate.js Datei gehen,

29
00:02:59,260 --> 00:03:01,780
und in authenticate.js Datei werden wir

30
00:03:01,780 --> 00:03:10,700
jetzt die JWT Strategie erstellen.

31
00:03:11,250 --> 00:03:16,175
Dies ist die JSON Web-Token Strategie, die von

32
00:03:16,175 --> 00:03:25,830
unserem Pass JWT Knotenmodul zur Verfügung gestellt wird, das wir gerade aufgenommen haben und so werden wir sagen,

33
00:03:26,300 --> 00:03:32,895
Generativitätsstrategie Pass generativity.strategy.

34
00:03:32,895 --> 00:03:35,370
Dies wird uns

35
00:03:35,370 --> 00:03:40,550
eine JSON Web Token basierte Strategie zur Konfiguration unseres Passport-Moduls bieten und

36
00:03:40,550 --> 00:03:46,820
dann JWT extrahieren, die ich

37
00:03:46,820 --> 00:03:53,745
auch von Pass JWT bekommen werde.

38
00:03:53,745 --> 00:03:55,935
Wir brauchen Pass JWT,

39
00:03:55,935 --> 00:03:59,565
dann sagen wir „Extrahieren JWT“.

40
00:03:59,565 --> 00:04:02,655
Dann lassen Sie uns

41
00:04:02,655 --> 00:04:10,240
das JSON Web Token-Modul importieren

42
00:04:10,240 --> 00:04:12,265
, das wir gerade installiert haben.

43
00:04:12,265 --> 00:04:15,340
Sobald wir diese importiert haben,

44
00:04:15,340 --> 00:04:18,370
lassen Sie uns fortfahren und beginnen, ein paar Dinge zu konfigurieren.

45
00:04:18,370 --> 00:04:26,205
Lassen Sie mich zusammen mit diesen die Konfiguration importieren, die ich

46
00:04:26,205 --> 00:04:35,840
die Datei config.js erstellt habe, die ich gerade meinem Projekt hinzugefügt habe.

47
00:04:35,840 --> 00:04:40,100
Sobald ich das abgeschlossen habe, lassen Sie mich weitermachen und

48
00:04:40,100 --> 00:04:45,650
ein paar zusätzliche Funktionen vorstellen, die ich von hier exportieren werde.

49
00:04:45,650 --> 00:04:49,200
Wir werden sagen, exports.GetToken,

50
00:04:55,160 --> 00:05:02,840
diese Funktion, wenn Sie dort einen Parameter bereitstellen, den ich einfach den Benutzer aufrufen

51
00:05:02,840 --> 00:05:06,335
werde, der ein JSON-Objekt sein wird,

52
00:05:06,335 --> 00:05:10,145
wird dies das Token erstellen und es für uns geben.

53
00:05:10,145 --> 00:05:16,685
Um das Token zu erstellen, verwenden wir das jsonwebtoken-Modul, das wir gerade importiert haben.

54
00:05:16,685 --> 00:05:22,140
Also, hier werden wir sagen, return jwt.sign,

55
00:05:23,750 --> 00:05:31,355
das hilft uns, das JSON Web Token zu erstellen und so innerhalb, dass es

56
00:05:31,355 --> 00:05:34,430
mir erlaubt, die Nutzlast zu liefern und

57
00:05:34,430 --> 00:05:38,825
die Nutzlast hier kommt als Parameter hier namens user,

58
00:05:38,825 --> 00:05:42,620
und dann ist der zweite Parameter der

59
00:05:42,620 --> 00:05:51,050
geheime oder private Schlüssel, den ich von der Konfiguration bekomme. geheimen Schlüssel

60
00:05:51,050 --> 00:05:55,260
, den ich gerade ein wenig früher konfiguriert habe.

61
00:05:55,630 --> 00:06:02,835
Wir können hier zusätzliche Optionen anbieten.

62
00:06:02,835 --> 00:06:07,055
Eine Option, die ich dazu liefern werde, ist...

63
00:06:07,055 --> 00:06:09,410
Okay, lassen Sie mich zur nächsten Zeile hier gehen,

64
00:06:09,410 --> 00:06:14,160
die Option, die ich liefern werde, ist ExpiResin.

65
00:06:14,530 --> 00:06:20,945
Das ExpiResin wird Ihnen sagen, wie lange das jsonwebtoken

66
00:06:20,945 --> 00:06:27,185
gültig sein wird, also sage ich in diesem Fall 3,600 Sekunden oder etwa eine Stunde.

67
00:06:27,185 --> 00:06:32,825
Eine Stunde später müssen Sie das jsonwebtoken erneuern.

68
00:06:32,825 --> 00:06:36,790
Eine Stunde ist lang genug, um unsere Anwendung testen zu können.

69
00:06:36,790 --> 00:06:40,370
Sie können dies so einstellen, dass es viel länger ist, wenn Sie sich dafür entscheiden.

70
00:06:40,370 --> 00:06:45,110
In einer echten Anwendung können Sie dies auf einen viel längeren Wert einstellen, vielleicht

71
00:06:45,110 --> 00:06:50,075
ein paar Tage und erwarten, dass sich der Benutzer alle paar Tage erneut authentifiziert.

72
00:06:50,075 --> 00:06:52,670
Jetzt werden wir auch als nächstes

73
00:06:52,670 --> 00:06:58,025
die jsonwebtoken basierte Strategie für unsere Passanwendung konfigurieren.

74
00:06:58,025 --> 00:07:02,900
Lassen Sie mich also eine Variable namens opts deklarieren,

75
00:07:02,900 --> 00:07:12,140
was nichts anderes als die Optionen ist, die ich für meine JWT-basierte Strategie angeben werde.

76
00:07:12,140 --> 00:07:18,905
Also werden wir sagen, entscheidet sich JWTFromRequest.

77
00:07:18,905 --> 00:07:22,925
Nun gibt diese Option an,

78
00:07:22,925 --> 00:07:28,580
wie das jsonwebtoken aus der eingehenden Anforderungsnachricht extrahiert werden soll.

79
00:07:28,580 --> 00:07:33,755
Dies ist, wo wir den Extrakt JWT verwenden.

80
00:07:33,755 --> 00:07:39,290
Dieser Extrakt JWT unterstützt verschiedene Methoden

81
00:07:39,290 --> 00:07:44,970
zum Extrahieren von Informationen aus dem Header.

82
00:07:44,970 --> 00:07:49,580
Es wird von AuthHeader von AuthHeader als Bearer-Token sagen,

83
00:07:49,580 --> 00:07:51,510
vom Header welches Schema und so weiter.

84
00:07:51,510 --> 00:07:54,380
Wenn Sie die Dokumentation lesen, erfahren

85
00:07:54,380 --> 00:07:58,040
Sie verschiedene Möglichkeiten, das jsonwebtoken zu extrahieren.

86
00:07:58,040 --> 00:08:00,770
Sie können das Token im Hauptteil

87
00:08:00,770 --> 00:08:04,970
der eingehenden Anforderungsnachricht übergeben und dann können Sie es von dort extrahieren,

88
00:08:04,970 --> 00:08:08,255
Sie können auch benutzerdefinierte Extraktoren verwenden usw.

89
00:08:08,255 --> 00:08:14,180
In diesem Kurs werde ich die einfachste Methode verwenden, die

90
00:08:14,180 --> 00:08:20,745
vom Authentifizierungsheader als Bearer-Token aufgerufen wird.

91
00:08:20,745 --> 00:08:22,220
Wir sind bereits mit

92
00:08:22,220 --> 00:08:25,055
dem Authentication Header vertraut, weil wir das mit

93
00:08:25,055 --> 00:08:30,440
der grundlegenden Authentifizierung und der Cookie-basierten Authentifizierung früher verwendet haben.

94
00:08:30,440 --> 00:08:32,180
Also, ich werde nur

95
00:08:32,180 --> 00:08:38,350
das gleiche Header-Feld in der Anforderungsnachricht verwenden, um das jsonwebtoken zu tragen.

96
00:08:38,350 --> 00:08:45,270
Also werde ich sagen, dass sich als Bearer-Token jsonwebtoken entscheidet.

97
00:08:45,270 --> 00:08:51,160
Der nächste, den wir sagen, Opts.SecretorKey,

98
00:08:56,980 --> 00:09:02,795
dies ist der zweite Parameter, der mir hilft

99
00:09:02,795 --> 00:09:11,670
, den geheimen Schlüssel zu liefern, den ich in meiner Strategie für die Anmeldung verwenden werde.

100
00:09:11,670 --> 00:09:15,875
Das ist also die andere Option, die ich hier angeben werde.

101
00:09:15,875 --> 00:09:18,065
Sobald ich diese beiden angegeben habe,

102
00:09:18,065 --> 00:09:26,390
lassen Sie mich die Passport-Strategie exportieren,

103
00:09:26,390 --> 00:09:30,680
die ich hier konfigurieren werde, so dass wir ExportJWTPassport sagen,

104
00:09:30,680 --> 00:09:34,355
dann sagen wir passport.use.

105
00:09:34,355 --> 00:09:37,940
Erinnern Sie sich an die Art und Weise, wie Sie die lokale Strategie zuvor angegeben

106
00:09:37,940 --> 00:09:42,035
Hier spezifizieren wir die JWT-basierte Strategie,

107
00:09:42,035 --> 00:09:47,895
dann werden wir eine neue JWT-Strategie erstellen,

108
00:09:47,895 --> 00:09:51,320
daran erinnern, dass wir gerade die JWT-Strategie

109
00:09:51,320 --> 00:09:56,615
hier importiert haben, das ist, was wir verwenden werden, um eine neue Strategie zu erstellen.

110
00:09:56,615 --> 00:10:01,235
Diese JWT-Strategie nimmt

111
00:10:01,235 --> 00:10:07,675
das Optionsobjekt, das ich gerade als ersten Parameter erstellt habe.

112
00:10:07,675 --> 00:10:14,210
Die Strategieoptionen und die zweite ist die Verifizierungsfunktion, die ich liefern muss,

113
00:10:14,210 --> 00:10:18,050
und so die Verifizierungsfunktion werde ich es in der nächsten Zeile hier liefern,

114
00:10:18,050 --> 00:10:28,545
sagen wir FunctionJWT_Payload.

115
00:10:28,545 --> 00:10:33,900
Fertig. Wenn diese Funktion aufgerufen wird, ist

116
00:10:33,900 --> 00:10:39,270
der Callback, der durch den Pass bereitgestellt wird.

117
00:10:39,270 --> 00:10:44,270
Also, wenn Sie einen Reisepass haben, den Sie mit einer neuen Strategie konfigurieren,

118
00:10:44,270 --> 00:10:46,750
müssen Sie den zweiten Parameter fertig angeben.

119
00:10:46,750 --> 00:10:48,460
Durch diesen fertigen

120
00:10:48,460 --> 00:10:52,235
Parameter werden Sie Informationen an den Reisepass zurückgeben, die er dann

121
00:10:52,235 --> 00:10:57,780
zum Laden von Dingen auf die Anforderungsnachricht verwenden wird.

122
00:10:57,780 --> 00:11:00,710
Wenn der Pass also die Anforderungsnachricht analysiert,

123
00:11:00,710 --> 00:11:04,110
wird er die Strategie verwenden und dann Informationen extrahieren

124
00:11:04,110 --> 00:11:09,540
und dann in unsere Anforderungsnachricht laden.

125
00:11:09,540 --> 00:11:13,905
Also, da dies eine Funktion ist,

126
00:11:13,905 --> 00:11:19,795
werde ich hier nur eine Pfeilfunktion verwenden,

127
00:11:19,795 --> 00:11:22,160
ich habe Pfeilfunktionen geliebt.

128
00:11:22,160 --> 00:11:25,650
Lassen Sie mich das also als Pfeilfunktion hier erstellen,

129
00:11:25,650 --> 00:11:28,345
und innerhalb dieser Funktion

130
00:11:28,345 --> 00:11:30,465
werden wir die Funktion definieren.

131
00:11:30,465 --> 00:11:32,970
Also, was machen wir innerhalb der Funktion?

132
00:11:32,970 --> 00:11:37,420
Lassen Sie mich eine console.log von

133
00:11:38,370 --> 00:11:44,020
JWT Payload machen und dann

134
00:11:44,660 --> 00:11:49,995
lassen Sie mich einfach die hier einkommende Option ausloggen,

135
00:11:49,995 --> 00:11:51,770
die JWT Payload Option kommt hier,

136
00:11:51,770 --> 00:11:55,420
so dass Sie sehen können, was in der JWT Payload ist.

137
00:11:55,420 --> 00:12:04,250
Dann werden wir nach einem Benutzer suchen, indem wir User.findone sagen,

138
00:12:04,250 --> 00:12:14,020
und dann weiß ich, dass es in der jwt.payload

139
00:12:14,020 --> 00:12:17,210
ein ID-Feld gibt, das eingeht.

140
00:12:17,210 --> 00:12:21,360
Also, das werde ich hier als ID-Feld zuweisen.

141
00:12:21,360 --> 00:12:26,040
Also, ich werde sagen, User.Findone und der zweite

142
00:12:26,040 --> 00:12:36,190
ist eine Callback-Funktion.

143
00:12:36,870 --> 00:12:45,295
Wie Sie erkennen, dieser Benutzer Mongoose Methode und Sie versuchen zu finden.

144
00:12:45,295 --> 00:12:54,665
Also, wir werden sagen, wenn irre dann, Rückkehr getan.

145
00:12:54,665 --> 00:12:57,945
Was hat das gemacht? Dies geschieht ist der Rückruf, den

146
00:12:57,945 --> 00:13:02,155
Pass in Ihre Strategie hier übergehen wird.

147
00:13:02,155 --> 00:13:04,965
Also werden wir diese fertige Funktion aufrufen.

148
00:13:04,965 --> 00:13:11,200
Dies geschieht im Reisepass nimmt drei Parameter.

149
00:13:12,890 --> 00:13:20,400
Also, Sie können die drei Stücke von Informationen sehen, die dies getan erwartet, es sagt, Fehler: alle.

150
00:13:20,400 --> 00:13:24,525
Also, wenn Sie einen Fehler haben, werden Sie ihn als ersten Parameter übergeben.

151
00:13:24,525 --> 00:13:26,495
Der zweite Parameter, Benutzer? ,

152
00:13:26,495 --> 00:13:28,245
Wenn ein Benutzer existiert,

153
00:13:28,245 --> 00:13:33,770
dann wird der Benutzerwert übergeben und dann, wenn irgendwelche Informationen? :, beliebig.

154
00:13:33,770 --> 00:13:37,100
Also, diese beiden sind optionale Parameter und

155
00:13:37,100 --> 00:13:38,690
wenn Sie Informationen übergeben,

156
00:13:38,690 --> 00:13:42,145
dann wird das innerhalb der Anwendung verwendet.

157
00:13:42,145 --> 00:13:44,650
Wenn ich false als zweiten Parameter übergebe,

158
00:13:44,650 --> 00:13:47,515
bedeutet das, dass der Benutzer nicht existiert oder das.

159
00:13:47,515 --> 00:13:50,810
Es wird also interpretieren, dass der Benutzer nicht existiert.

160
00:13:50,810 --> 00:13:52,335
Also, ich könnte sagen, äh,

161
00:13:52,335 --> 00:13:54,900
falsch, weil dies ein Fehler ist.

162
00:13:54,900 --> 00:13:58,080
Also, ich werde dort keinen Benutzerwert übergeben,

163
00:13:58,080 --> 00:14:00,660
ich werde nur falsch übergeben.

164
00:14:00,660 --> 00:14:06,040
Dort, die nächste,

165
00:14:06,040 --> 00:14:11,510
können wir sagen, sonst wenn (Benutzer).

166
00:14:11,510 --> 00:14:15,860
Also, wenn der Benutzer nicht null ist,

167
00:14:15,860 --> 00:14:18,960
sagen wir return done (null).

168
00:14:19,230 --> 00:14:22,210
Es gibt keinen Fehler, also wird der erste Parameter

169
00:14:22,210 --> 00:14:25,080
null sein und der zweite Parameter ist der Benutzer,

170
00:14:25,080 --> 00:14:29,895
aber wir haben gerade von der MongoDB bekommen.

171
00:14:29,895 --> 00:14:35,445
Andernfalls werden wir

172
00:14:35,445 --> 00:14:41,395
mit null, false zurück.

173
00:14:41,395 --> 00:14:43,650
Also, im letzten Fall

174
00:14:43,650 --> 00:14:45,100
konnten wir den Benutzer nicht finden,

175
00:14:45,100 --> 00:14:47,120
also werden wir falsch übergeben.

176
00:14:47,120 --> 00:14:50,200
Also, wir werden es so behandeln.

177
00:14:50,200 --> 00:14:53,345
Wenn Sie möchten, können Sie an dieser Stelle ein neues Benutzerkonto erstellen,

178
00:14:53,345 --> 00:14:58,365
aber ich werde dies einfach halten, nur damit es für uns leicht zu verstehen ist.

179
00:14:58,365 --> 00:15:00,810
Also, wir sagen einfach, null, falsch. Das sind sechs.

180
00:15:00,810 --> 00:15:07,475
Also, das ist die JSONWebToken Passstrategie, die ich gerade hier konfiguriert habe.

181
00:15:07,475 --> 00:15:11,420
Lassen Sie mich auch

182
00:15:11,420 --> 00:15:19,450
eine weitere Funktion von hier namens VerifyUser exportieren.

183
00:15:19,450 --> 00:15:21,110
Nun, diese VerifyUser-Funktion,

184
00:15:21,110 --> 00:15:24,935
werde ich es verwenden, um einen eingehenden Benutzer zu überprüfen.

185
00:15:24,935 --> 00:15:28,810
Also, hier werde ich passport.authenticate verwenden.

186
00:15:28,890 --> 00:15:36,440
Also, die passport.authenticate, die Strategie ist jwt-Strategie, die ich gerade konfiguriert habe,

187
00:15:36,440 --> 00:15:39,490
die JSONWebToken-Strategie, die ich gerade konfiguriert habe.

188
00:15:39,490 --> 00:15:41,625
Dann, der zweite Teil,

189
00:15:41,625 --> 00:15:46,305
würde ich sagen, Sitzung: falsch.

190
00:15:46,305 --> 00:15:47,740
Das bedeutet also, dass

191
00:15:47,740 --> 00:15:51,305
wir in diesem Fall keine Sitzungen erstellen werden.

192
00:15:51,305 --> 00:15:58,215
Wie Sie sich erinnern, eine umgekehrte Anwendung,

193
00:15:58,215 --> 00:16:00,530
verwenden wir Token-basierte Authentifizierung.

194
00:16:00,530 --> 00:16:02,435
Also werden wir keine Sitzungen erstellen.

195
00:16:02,435 --> 00:16:07,690
Deshalb habe ich diese Optionssitzung hier auf false gesetzt,

196
00:16:07,690 --> 00:16:11,795
und natürlich hat die erste die Strategie angegeben, die ich verwenden werde.

197
00:16:11,795 --> 00:16:14,050
Also, um einen Benutzer zu verifizieren,

198
00:16:14,050 --> 00:16:15,930
werde ich die JWT-Strategie verwenden.

199
00:16:15,930 --> 00:16:18,110
Wie funktioniert die JWT-Strategie?

200
00:16:18,110 --> 00:16:20,540
In der eingehenden Anfrage

201
00:16:21,040 --> 00:16:26,845
wird das Token in den Authentifizierungs-Header aufgenommen, wie wir hier gesehen haben.

202
00:16:26,845 --> 00:16:29,950
Wir sagten, Authentifizierungs-Header als Bearer-Token.

203
00:16:29,950 --> 00:16:33,530
Wenn das enthalten ist, wird das extrahiert und das wird

204
00:16:33,530 --> 00:16:38,210
verwendet, um den Benutzer basierend auf dem Token zu authentifizieren.

205
00:16:38,210 --> 00:16:47,770
Geringfügige Korrektur hier sollte dies user.findone_id ist gleich jwt_payload. _id,

206
00:16:47,770 --> 00:16:56,475
da dies der ID-Wert ist, der sich innerhalb der Nutzlast meines JSONWebToken befindet.

207
00:16:56,475 --> 00:17:01,615
Also suchen wir nach dem Benutzer mit dieser angegebenen ID.

208
00:17:01,615 --> 00:17:06,170
Also, sobald wir dies abgeschlossen haben, dann jetzt,

209
00:17:06,170 --> 00:17:11,790
der zweite Teil, den wir tun müssen, ist, dass wir das Token irgendwo erstellen müssen.

210
00:17:11,790 --> 00:17:14,005
Nun, wo erstellen wir das Token?

211
00:17:14,005 --> 00:17:22,270
Also, hier ist etwas, das wir in der Datei users.js tun, sehr nützlich für uns.

212
00:17:22,270 --> 00:17:27,180
Erinnern Sie sich in der Datei users.js, dass Sie bereits diesen Endpunkt namens login haben.

213
00:17:27,180 --> 00:17:28,700
Auf dem Anmeldeendpunkt

214
00:17:28,700 --> 00:17:33,410
haben Sie den Benutzernamen und das Kennwort verwendet, um den Benutzer zu authentifizieren.

215
00:17:33,410 --> 00:17:38,030
Selbst mit dem JSONWebToken, um das JSONWebToken

216
00:17:38,030 --> 00:17:41,959
auszugeben, müssen Sie zuerst den Benutzer mit einer der anderen Strategien authentifizieren,

217
00:17:41,959 --> 00:17:44,630
und wenn Sie zuerst die lokale Strategie verwenden,

218
00:17:44,630 --> 00:17:49,715
werden wir den Benutzer mit dem Benutzernamen und dem Passwort authentifizieren.

219
00:17:49,715 --> 00:17:53,415
Sobald der Benutzer mit dem Benutzernamen und Passwort authentifiziert ist,

220
00:17:53,415 --> 00:17:55,885
werden wir das Token an den Benutzer ausgeben und sagen:

221
00:17:55,885 --> 00:17:57,330
„Okay, Sie sind ein gültiger Benutzer,

222
00:17:57,330 --> 00:17:58,630
ich werde Ihnen das Token geben“.

223
00:17:58,630 --> 00:18:02,390
Alle nachfolgenden Anfragen tragen einfach das Token

224
00:18:02,390 --> 00:18:06,860
in der Kopfzeile der eingehenden Anforderungsnachricht.

225
00:18:06,860 --> 00:18:10,415
Früher haben wir Sessions erstellt.

226
00:18:10,415 --> 00:18:11,840
Wenn der Benutzer authentifiziert ist,

227
00:18:11,840 --> 00:18:13,935
werden wir keine Sitzungen mehr verwenden.

228
00:18:13,935 --> 00:18:17,640
Stattdessen werden

229
00:18:17,640 --> 00:18:20,110
wir, wenn der Benutzer mit der lokalen Strategie authentifiziert wird, ein Token an den Benutzer ausgeben.

230
00:18:20,110 --> 00:18:25,955
Also, in dieser router.post-Methode, die wir auf diesem /login Endpunkt gemacht haben,

231
00:18:25,955 --> 00:18:31,730
werde ich ein Token erstellen und dieses Token an den Benutzer zurückgeben.

232
00:18:31,730 --> 00:18:36,980
Also, hier, werden wir sagen, ein router.Post.

233
00:18:38,550 --> 00:18:40,785
Lassen Sie mich ein Token erstellen.

234
00:18:40,785 --> 00:18:42,630
Um ein Token zu erstellen,

235
00:18:42,630 --> 00:18:50,150
haben wir diese Funktion im Authentifizierungsmodul namens Authenticate.GetToken.

236
00:18:51,250 --> 00:18:54,325
Also, erinnern Sie sich, dass wir bereits,

237
00:18:54,325 --> 00:18:57,050
um das natürlich nutzen zu können,

238
00:18:57,050 --> 00:18:59,210
noch bevor wir dort anfangen,

239
00:18:59,210 --> 00:19:02,750
Ich muss die Authentifizierung importieren.

240
00:19:05,940 --> 00:19:17,720
Modul hier. Also, wir werden sagen, authentifizieren erfordern. /authentifizieren.

241
00:19:18,000 --> 00:19:26,740
Also, wenn in Ihrem Code hier,

242
00:19:26,740 --> 00:19:29,270
können wir jetzt Authenticate.getToken sagen,

243
00:19:31,530 --> 00:19:37,585
und der GetToken nimmt Parameter hier.

244
00:19:37,585 --> 00:19:41,875
Nun, erinnern Sie sich, gehen Sie zurück authenticate.js Datei.

245
00:19:41,875 --> 00:19:46,665
Die Datei authenticate.js nimmt hier einen Parameter

246
00:19:46,665 --> 00:19:53,105
, der als Nutzlast verwendet wird, wenn Sie das JSONWebToken erstellen.

247
00:19:53,105 --> 00:19:55,785
Also, in der Datei users.js

248
00:19:55,785 --> 00:19:59,230
werde ich ein Token erstellen, indem ich eine Payload gebe,

249
00:19:59,230 --> 00:20:02,890
die nur die ID des Benutzers enthält.

250
00:20:02,890 --> 00:20:06,070
Also, wir sagen id: req.user. _id.

251
00:20:06,740 --> 00:20:11,940
Das reicht aus, um das JSONWebToken zu erstellen.

252
00:20:11,940 --> 00:20:15,315
Wir möchten keine weiteren Informationen des Nutzers hinzufügen.

253
00:20:15,315 --> 00:20:18,690
Wenn Sie sich entscheiden, können Sie andere Teile der Benutzerinformationen einschließen,

254
00:20:18,690 --> 00:20:21,715
aber ich würde vorschlagen, dass Sie den JSONWebToken klein halten.

255
00:20:21,715 --> 00:20:25,700
Die Benutzer-ID reicht aus, denn wenn Sie nach dem Benutzer suchen müssen,

256
00:20:25,700 --> 00:20:32,840
reicht die Benutzer-ID aus, um in der MongoDB nach dem Benutzer zu suchen.

257
00:20:32,840 --> 00:20:39,230
Also, ich werde nur die ID des Benutzers hier codieren.

258
00:20:39,230 --> 00:20:44,930
Nun wissen Sie, dass der req.user bereits vorhanden wäre,

259
00:20:44,930 --> 00:20:50,530
denn wenn passport.authenticate ('local') den Benutzer erfolgreich authentifiziert,

260
00:20:50,530 --> 00:20:54,650
wird dies die Benutzereigenschaft in die Anforderungsnachricht laden.

261
00:20:54,650 --> 00:20:57,300
Deshalb bin ich in der Lage, das hier zu tun.

262
00:20:57,300 --> 00:21:01,830
Also, das werde ich verwenden, um das Token zu erstellen.

263
00:21:01,900 --> 00:21:05,120
Sobald das Token erstellt wurde,

264
00:21:05,120 --> 00:21:09,720
möchte ich dieses Token an den Benutzer zurückgeben.

265
00:21:09,720 --> 00:21:15,715
Also, in dem rest.json-Objekt, das ich hier

266
00:21:15,715 --> 00:21:21,755
bereitstelle, trage ich bereits die wahre Erfolgsflagge und auch

267
00:21:21,755 --> 00:21:23,855
eine Statusmeldung hier.

268
00:21:23,855 --> 00:21:28,270
Lassen Sie mich das Token

269
00:21:28,270 --> 00:21:34,880
als eine der Eigenschaften in der Antwortnachricht hier hinzufügen.

270
00:21:36,480 --> 00:21:39,475
Also, das Token, das ich gerade erstellt habe,

271
00:21:39,475 --> 00:21:47,595
werde ich das als zweite Eigenschaft innerhalb dieser Json-Zeichenfolge hier zurückgeben.

272
00:21:47,595 --> 00:21:55,370
Also, wenn mein Client diese Json-Zeichenfolge im Hauptteil der Antwortnachricht empfängt,

273
00:21:55,370 --> 00:21:59,870
kann er eingehen und das Token von dort extrahieren.

274
00:22:00,140 --> 00:22:05,500
Das war's. So haben wir jetzt die Datei users.js aktualisiert,

275
00:22:05,500 --> 00:22:08,630
und Sie können jetzt sehen, wie das Token

276
00:22:08,630 --> 00:22:12,690
erstellt und an den Benutzer zurückgesendet wird, wenn der Benutzer erfolgreich authentifiziert wurde.

277
00:22:12,690 --> 00:22:16,330
Jetzt kann dieses Schema auch verwendet werden,

278
00:22:16,330 --> 00:22:21,250
wenn Sie Drittanbieter-Authentifizierung wie basierend auf OAuth 2.0 verwenden,

279
00:22:21,250 --> 00:22:23,525
die wir im nächsten Modul untersuchen werden.

280
00:22:23,525 --> 00:22:25,695
Jetzt wird das Verfahren ähnlich sein.

281
00:22:25,695 --> 00:22:28,880
Sie erstellen ein Token, wenn der Benutzer vom

282
00:22:28,880 --> 00:22:32,560
Drittanbieter- oder OAuth-Authentifizierungsanbieter authentifiziert

283
00:22:32,560 --> 00:22:35,640
wird, und dann übergeben Sie das Token an den Benutzer zurück,

284
00:22:35,640 --> 00:22:39,010
in einem ähnlichen Ansatz, wie Sie hier sehen.

285
00:22:39,010 --> 00:22:41,285
Jetzt, sobald wir dies getan haben,

286
00:22:41,285 --> 00:22:44,255
dann gehen wir zu app.js Datei.

287
00:22:44,255 --> 00:22:53,660
In app.js Datei, weil wir hier eine Konfigurationsdatei enthalten haben.

288
00:22:53,660 --> 00:22:59,005
Also, lassen Sie mich die Konfigurationsdatei hier benötigen,

289
00:22:59,005 --> 00:23:06,465
und dann die URL, die ich hier verwende, anstatt diese URL zu hardcodieren,

290
00:23:06,465 --> 00:23:11,345
werde ich config.mongoURL sagen.

291
00:23:11,345 --> 00:23:16,680
Jetzt sehen Sie, wie meine Datei config.js als

292
00:23:16,680 --> 00:23:23,520
zentralisierter Ort verwendet werden kann, an dem ich die Konfiguration für meine Anwendung vorbereiten kann.

293
00:23:23,520 --> 00:23:29,200
Das war's. Was jetzt passiert, ist, dass, wenn

294
00:23:29,200 --> 00:23:35,010
sich der Benutzer auf dem /login-Endpunkt authentifiziert und der Benutzer erfolgreich authentifiziert

295
00:23:35,010 --> 00:23:40,840
wird, das Token vom Server erstellt und an den Client oder den Benutzer zurückgesendet wird.

296
00:23:40,840 --> 00:23:43,765
Daher wird der Client das Token in

297
00:23:43,765 --> 00:23:47,765
jede nachfolgende eingehende Anforderung in den Autorisierungs-Header aufnehmen.

298
00:23:47,765 --> 00:23:50,590
Nun, wie enthält es den Autorisierungs-Header?

299
00:23:50,590 --> 00:23:54,220
Gehen wir zurück zu authentic.js und hier

300
00:23:54,220 --> 00:24:01,625
sehen Sie, dass wir hier ExtractJWT.fromAuthHeaderAsBearerToken gesagt haben.

301
00:24:01,625 --> 00:24:06,290
Dies wird also in den Authentifizierungsheader als Bearer-Token enthalten sein.

302
00:24:06,290 --> 00:24:08,385
Ich zeige Ihnen, wie das gemacht wird,

303
00:24:08,385 --> 00:24:15,535
dann verwenden wir Postman, um das Bearer-Token in den Authentifizierungs-Header aufzunehmen.

304
00:24:15,535 --> 00:24:17,690
Nun, wenn dies eintritt,

305
00:24:17,690 --> 00:24:21,060
dann erinnern Sie sich, dass

306
00:24:21,060 --> 00:24:25,095
Sie unten hier diese Methode hier namens VerifyUser konfiguriert haben,

307
00:24:25,095 --> 00:24:30,635
die die Passauthentifizierung mit JWT aufruft.

308
00:24:30,635 --> 00:24:34,460
Also, dieser verwendet das Token, das

309
00:24:34,460 --> 00:24:38,620
in der Authentifizierungsheader kommt und überprüft dann den Benutzer.

310
00:24:38,620 --> 00:24:41,980
Also, jedes Mal, wenn ich die Authentizität des Benutzers überprüfen möchte,

311
00:24:41,980 --> 00:24:43,855
kann ich einfach verify user aufrufen,

312
00:24:43,855 --> 00:24:49,115
und das wird den Aufruf an den passport.authenticate initiieren und den SSER überprüfen.

313
00:24:49,115 --> 00:24:50,315
Wenn dies erfolgreich ist,

314
00:24:50,315 --> 00:24:51,800
wird es mir erlauben, fortzufahren.

315
00:24:51,800 --> 00:24:55,620
Diese Prozedur ähnelt dem, was Sie in der

316
00:24:55,620 --> 00:25:01,610
Datei users.js getan haben, wo Sie denselben passport.authenticate ('local') aufrufen.

317
00:25:01,720 --> 00:25:04,320
Also, wenn das erfolgreich ist,

318
00:25:04,320 --> 00:25:05,885
dann gehst du vorwärts.

319
00:25:05,885 --> 00:25:10,930
Wenn dies fehlschlägt, gibt die Authentifizierungsfunktion die Fehlermeldung an den

320
00:25:10,930 --> 00:25:16,050
Client zurück, der besagt, dass der Benutzer nicht autorisiert ist.

321
00:25:16,050 --> 00:25:18,345
Also, das ist schon gesorgt.

322
00:25:18,345 --> 00:25:23,020
Nun, da wir dies in meine authenticate.js Datei aufgenommen haben,

323
00:25:23,020 --> 00:25:26,050
an jedem Ort, an dem ich den Benutzer überprüfen möchte,

324
00:25:26,050 --> 00:25:27,480
kann ich einfach

325
00:25:27,480 --> 00:25:31,210
diese VerifyUser-Funktion aufrufen, die

326
00:25:31,210 --> 00:25:34,320
ich hier angegeben habe, oder den Export, den ich hier angegeben habe

327
00:25:34,320 --> 00:25:37,220
, den wir auf den passport.authenticate mit

328
00:25:37,220 --> 00:25:40,540
die JWT-Strategie, um den Benutzer zu authentifizieren.

329
00:25:40,540 --> 00:25:42,440
Nun, wie nutzen wir das?

330
00:25:42,440 --> 00:25:47,785
Nun, was wir tun werden, ist, dass wir in jeden einzelnen unserer Router gehen

331
00:25:47,785 --> 00:25:56,945
und die Optionen auf allen Routen steuern, die wir kontrollieren wollen.

332
00:25:56,945 --> 00:26:00,300
Also, zurück zur Datei app.js, jetzt,

333
00:26:00,300 --> 00:26:07,925
dass wir keine Sitzungen verwenden, werde ich diese Sitzung von hier entfernen,

334
00:26:07,925 --> 00:26:10,150
weil wir keine Sitzungen mehr verwenden.

335
00:26:10,150 --> 00:26:14,990
In ähnlicher Weise werde ich diesen passport.session auch von hier entfernen.

336
00:26:14,990 --> 00:26:17,580
Das ist auch nicht nötig.

337
00:26:17,580 --> 00:26:20,430
Diese Authentifizierung, siehe oben,

338
00:26:20,430 --> 00:26:21,940
als ich diese Authentifizierung konfiguriert habe,

339
00:26:21,940 --> 00:26:25,490
wurde diese Authentifizierung auf jede einzelne eingehende Anforderung angewendet.

340
00:26:25,490 --> 00:26:28,705
Jetzt werde ich meine Anwendung ändern,

341
00:26:28,705 --> 00:26:35,055
wobei ich die Authentifizierung nur auf bestimmten Routen und nicht auf allen Routen erfordern werde.

342
00:26:35,055 --> 00:26:39,665
Also, lassen Sie mich diese Authentifizierung vollständig aus app.js entfernen.

343
00:26:39,665 --> 00:26:41,995
Also, wenn die Anfrage eingeht,

344
00:26:41,995 --> 00:26:45,850
wenn sie auf/Endpunkt ist,

345
00:26:45,850 --> 00:26:47,080
wird der Index bereitgestellt.

346
00:26:47,080 --> 00:26:52,040
Wenn es sich am Endpunkt /users befindet, können Sie zu

347
00:26:52,040 --> 00:26:57,815
den verschiedenen Routen navigieren, die auf der /users in der users.js

348
00:26:57,815 --> 00:27:00,900
und anschließend zu den restlichen Routen eingehängt sind.

349
00:27:00,900 --> 00:27:03,420
Was ich jetzt tun werde, ist, dass ich

350
00:27:03,420 --> 00:27:07,250
den öffentlichen Ordner offen lassen werde, damit jeder Zugriff hat.

351
00:27:07,250 --> 00:27:09,145
In vielen Anwendungen

352
00:27:09,145 --> 00:27:10,665
kann dies in Ordnung sein.

353
00:27:10,665 --> 00:27:13,045
Also werde ich das offen lassen.

354
00:27:13,045 --> 00:27:14,825
Nun, auf die Gerichte,

355
00:27:14,825 --> 00:27:17,920
Promotionen, und der Endpunkt der Führer,

356
00:27:17,920 --> 00:27:20,875
Alle Get-Anfragen.

357
00:27:20,875 --> 00:27:28,205
Ich werde diese ohne Authentifizierung antworten lassen.

358
00:27:28,205 --> 00:27:30,200
Warum sollte ich das tun wollen?

359
00:27:30,200 --> 00:27:33,190
Wenn ein Benutzer eine Get-Anforderung

360
00:27:33,190 --> 00:27:35,455
ausführt, möchte der Benutzer nur Informationen abrufen.

361
00:27:35,455 --> 00:27:40,490
Also, zum Beispiel, auf der Client-Seite, wenn ich eine Webanwendung mit Angular

362
00:27:40,490 --> 00:27:46,290
oder einer Client-Anwendung mit Ionic oder nativem Skript implementiere,

363
00:27:46,290 --> 00:27:49,920
dann möchte ich meine App vielleicht

364
00:27:49,920 --> 00:27:54,310
so implementieren, dass die Hauptseite bereits Informationen anzeigt,

365
00:27:54,310 --> 00:27:57,715
die genetischen Informationen, die Sie möchten Stellen Sie jedem zur Verfügung, der

366
00:27:57,715 --> 00:28:01,590
Ihre Website besucht oder Ihre App öffnet.

367
00:28:01,590 --> 00:28:04,360
So können dort grundlegende Informationen angezeigt werden.

368
00:28:04,360 --> 00:28:08,060
Wenn Sie jedoch etwas ändern möchten,

369
00:28:08,060 --> 00:28:12,110
erwarten Sie, dass der Benutzer authentifiziert wird.

370
00:28:12,110 --> 00:28:16,255
So erlauben Sie POST-Operationen, Put-Operationen

371
00:28:16,255 --> 00:28:21,110
und Löschvorgänge nur von authentifizierten Benutzern ausgeführt werden.

372
00:28:21,110 --> 00:28:23,605
In ähnlicher Weise

373
00:28:23,605 --> 00:28:30,280
können Sie beispielsweise für Kommentare sagen, dass Kommentare nur von authentifizierten Benutzern gepostet oder geändert werden können.

374
00:28:30,280 --> 00:28:34,570
So können Sie nur einige Routen für authentifizierte Benutzer einschränken,

375
00:28:34,570 --> 00:28:37,940
die andere Route können Sie sie offen lassen. Wie machen wir das?

376
00:28:37,940 --> 00:28:41,180
Jetzt ist dies, wo der Benutzer überprüfen, dass wir

377
00:28:41,180 --> 00:28:45,055
aus authenticate.js Datei exportiert haben, nützlich ist.

378
00:28:45,055 --> 00:28:49,460
Jetzt, anstatt alle Endpunkte,

379
00:28:49,460 --> 00:28:53,190
alle verschiedenen Operationen auf die Gerichte, Aktionen

380
00:28:53,190 --> 00:28:54,740
und Führer in Punkten zu kontrollieren,

381
00:28:54,740 --> 00:28:58,240
werden wir nur die Get-Operationen für jedermann öffnen,

382
00:28:58,240 --> 00:29:00,830
aber die Post, Put-

383
00:29:00,830 --> 00:29:04,995
und Löschvorgänge werden nur auf authentifizierte Benutzer beschränkt.

384
00:29:04,995 --> 00:29:10,350
In der Zuweisung fügen Sie eine weitere Kategorie von Benutzern hinzu, die Admin-Benutzer genannt werden.

385
00:29:10,350 --> 00:29:15,320
Jetzt würden Sie bestimmte Vorgänge einschränken, die nur von Administratorbenutzern ausgeführt werden.

386
00:29:15,320 --> 00:29:18,460
So, zum Beispiel, das Ändern der Gerichte

387
00:29:18,460 --> 00:29:22,530
oder das Löschen der Gerichte Informationen aus der Datenbank,

388
00:29:22,530 --> 00:29:24,600
wird nur auf Admin-Benutzer beschränkt sein.

389
00:29:24,600 --> 00:29:30,000
Aber grundlegende Benutzer können Kommentare posten,

390
00:29:30,000 --> 00:29:32,470
die Kommentare ändern, die sie gepostet haben,

391
00:29:32,470 --> 00:29:35,450
und vielleicht sogar einige Lieblingsgerichte speichern.

392
00:29:35,450 --> 00:29:38,520
Wir machen diesen Teil im vierten Modul.

393
00:29:38,520 --> 00:29:42,735
Nun, wie steuern wir bestimmte Routen?

394
00:29:42,735 --> 00:29:46,210
Hier müssen wir in jeden der Router gehen

395
00:29:46,210 --> 00:29:50,365
und dann Kontrollen auf bestimmten Routen importieren.

396
00:29:50,365 --> 00:29:53,945
Also, lassen Sie uns mit der Geschirr Route beginnen.

397
00:29:53,945 --> 00:29:55,770
Also, für die Gerichte Route,

398
00:29:55,770 --> 00:29:59,950
werden Sie sich erinnern, dass dies in der Datei dishRouter.js gesteuert wird.

399
00:29:59,950 --> 00:30:02,515
Also, gehen Sie zu dishRouter.js,

400
00:30:02,515 --> 00:30:07,450
lassen Sie uns zuerst die Authentifizierung hier importieren.

401
00:30:07,450 --> 00:30:13,400
Also werden wir sagen, const authenticate

402
00:30:17,010 --> 00:30:24,700
require../authentifizieren, weil

403
00:30:24,700 --> 00:30:29,110
sich diese authenticator.js Datei im Ordner der höheren Ebene befindet.

404
00:30:29,110 --> 00:30:32,105
Also, denken Sie daran../authentifizieren Sie sich hier.

405
00:30:32,105 --> 00:30:34,505
Also, sobald Sie die Authentifizierung importieren,

406
00:30:34,505 --> 00:30:37,965
für die Dish-Router-Route für diese Route,

407
00:30:37,965 --> 00:30:42,560
die Get-Operation, werde ich ohne Probleme zulassen.

408
00:30:42,560 --> 00:30:44,820
Also, das ist offen.

409
00:30:44,820 --> 00:30:47,025
Also werde ich keine Einschränkung auferlegen.

410
00:30:47,025 --> 00:30:51,750
Von der Post, wenn wir mehrere Middleware anwenden möchten,

411
00:30:51,750 --> 00:30:56,035
können wir einfach die Haupt in diesem einen hinter dem anderen hinzufügen.

412
00:30:56,035 --> 00:30:58,050
Jetzt, wenn der Beitrag aufgerufen wird, führen

413
00:30:58,050 --> 00:31:02,295
Sie gerade jetzt einfach diese Funktion hier aus.

414
00:31:02,295 --> 00:31:04,150
Jetzt kurz davor

415
00:31:04,150 --> 00:31:12,400
kann ich hineingehen und sagen, Authenticate.verifyUser, dort.

416
00:31:12,400 --> 00:31:13,805
Also, was macht das?

417
00:31:13,805 --> 00:31:17,210
Dies besagt, dass, wenn eine Post-Anfrage hereinkommt,

418
00:31:17,210 --> 00:31:20,940
ich zuerst diese Middleware ausführen würde,

419
00:31:20,940 --> 00:31:24,805
die ich aus der Datei authentic.js exportiert habe.

420
00:31:24,805 --> 00:31:26,100
Ich wende das zuerst

421
00:31:26,100 --> 00:31:32,075
an, was entspricht, dass Pass authentifizieren JWT und Sie überprüfen den Benutzer.

422
00:31:32,075 --> 00:31:34,655
Dann, wenn das erfolgreich ist,

423
00:31:34,655 --> 00:31:38,890
dann werde ich den Rest davon machen.

424
00:31:38,890 --> 00:31:42,955
Wenn die Authentifizierung zu diesem Zeitpunkt fehlschlägt,

425
00:31:42,955 --> 00:31:46,290
antwortet die Passauthentifizierung

426
00:31:46,290 --> 00:31:49,395
dem Client mit der entsprechenden Fehlermeldung.

427
00:31:49,395 --> 00:31:51,640
Das wird also bereits durch Passauthentifizierung gehandhabt,

428
00:31:51,640 --> 00:31:54,350
also muss ich mir nichts darüber hinaus Sorgen machen.

429
00:31:54,350 --> 00:31:58,300
Wenn ich diese Middleware überschritten habe und dann

430
00:31:58,300 --> 00:32:02,990
die nächste Funktion ausführen kann, bedeutet das, dass meine Authentifizierung erfolgreich war,

431
00:32:02,990 --> 00:32:05,560
also kann ich von diesem Punkt aus vorwärts gehen.

432
00:32:05,560 --> 00:32:11,760
Dies wirkt also als Barriere für diese Post-Methode.

433
00:32:11,760 --> 00:32:14,860
Jetzt mit dem gleichen Argument

434
00:32:14,860 --> 00:32:21,435
kann ich diese bestimmte Middleware einfach auf alle anderen Methoden anwenden.

435
00:32:21,435 --> 00:32:23,845
Das kann ich dem Putt antun.

436
00:32:23,845 --> 00:32:26,030
Obwohl in diesem Fall,

437
00:32:26,030 --> 00:32:28,640
Put wird nichts tun.

438
00:32:28,640 --> 00:32:30,110
Aber in jedem Fall

439
00:32:30,110 --> 00:32:33,980
werde ich einfach nur aus Gründen der Einheitlichkeit,

440
00:32:33,980 --> 00:32:38,490
Ich werde den verifizierenden Benutzer anwenden, um auch zu setzen und natürlich,

441
00:32:38,490 --> 00:32:41,315
zum Löschen auch, werde ich setzen anwenden.

442
00:32:41,315 --> 00:32:44,805
In ähnlicher Weise, wenn ich auf die /dishid

443
00:32:44,805 --> 00:32:48,915
gehe, werde ich zulassen, dass ohne Probleme funktioniert.

444
00:32:48,915 --> 00:32:52,470
Posten, Ich werde den Verifizierungsbenutzer anwenden.

445
00:32:52,470 --> 00:32:59,600
Setzen Sie auch ich werde den Benutzer verifizieren und zum Löschen auch dasselbe anwenden.

446
00:32:59,600 --> 00:33:09,105
Für die /dishid/comments werde ich das get open lassen,

447
00:33:09,105 --> 00:33:14,030
es ist in Ordnung für jeden, Kommentare zu einem bestimmten Gericht abzurufen.

448
00:33:14,030 --> 00:33:17,140
Post, ich werde dies schließen,

449
00:33:17,140 --> 00:33:21,995
so dass nur verifizierte Benutzer Kommentare posten können.

450
00:33:21,995 --> 00:33:27,710
Setzen Sie auch ich werde das schließen und auch löschen.

451
00:33:29,280 --> 00:33:33,035
Sie müssen einen Schritt weiter gehen und sagen:

452
00:33:33,035 --> 00:33:38,230
„Nur die Benutzer, die den Kommentar gepostet haben, können ihre eigenen Beiträge löschen.“

453
00:33:38,230 --> 00:33:40,310
Aber das werden wir im nächsten Modul tun.

454
00:33:40,310 --> 00:33:41,840
Im Moment werde ich sagen:

455
00:33:41,840 --> 00:33:44,415
„Okay, ein verifizierter Benutzer kann jeden Kommentar löschen.“

456
00:33:44,415 --> 00:33:46,715
Das ist natürlich nicht wahr,

457
00:33:46,715 --> 00:33:48,850
wir können zusätzliche Kontrollen vornehmen,

458
00:33:48,850 --> 00:33:52,145
aber wir werden das im nächsten Modul dieses Kurses tun.

459
00:33:52,145 --> 00:33:54,405
Also, zum Löschen auch wende ich dasselbe an.

460
00:33:54,405 --> 00:33:58,060
Auch hier, für den Teller Router Kommentare/Kommentare Id,

461
00:33:58,060 --> 00:34:00,300
bekomme ich es als offen lassen.

462
00:34:00,300 --> 00:34:04,485
Post, ich werde es geschlossen lassen.

463
00:34:04,485 --> 00:34:12,640
Setzen Sie auch schließen Sie es ab und dann zum Löschen werde ich auch das schließen.

464
00:34:12,640 --> 00:34:14,970
Löschen Sie natürlich, wie gesagt,

465
00:34:14,970 --> 00:34:19,180
der Löschvorgang sollte nur einem Benutzer erlaubt werden,

466
00:34:19,180 --> 00:34:24,150
der den Kommentar erstellt hat, sollte gebeten werden, das

467
00:34:24,150 --> 00:34:27,960
zu löschen, aber Sie müssen ein paar zusätzliche Dinge einrichten, damit das korrekt funktioniert,

468
00:34:27,960 --> 00:34:30,825
was wir im nächsten Modul tun werden.

469
00:34:30,825 --> 00:34:36,455
Im Moment sagen wir, dass ein verifizierter Benutzer einen bestimmten Kommentar löschen kann, das war's.

470
00:34:36,455 --> 00:34:42,820
Jetzt werden wir das gleiche Prinzip auf den Promo-Router und auch den Leader Router anwenden.

471
00:34:42,820 --> 00:34:44,950
Also, gehen Sie in den Promo-Router,

472
00:34:44,950 --> 00:34:53,100
lassen Sie mich importieren authentifizieren

473
00:34:57,320 --> 00:35:00,870
und dann bekommen ist offen,

474
00:35:00,870 --> 00:35:03,540
also ist dies Leader Router.

475
00:35:03,540 --> 00:35:05,380
Also, get ist offen.

476
00:35:05,380 --> 00:35:08,365
Post, Ich werde zu kontrollieren, dass,

477
00:35:08,365 --> 00:35:12,865
setzen, steuern, löschen, steuern,

478
00:35:12,865 --> 00:35:14,790
Führer Router, Führer ID,

479
00:35:14,790 --> 00:35:17,255
bekommen ist in Ordnung, Post

480
00:35:17,255 --> 00:35:22,330
, gesteuert, setzen wird gesteuert und löschen gesteuert.

481
00:35:22,330 --> 00:35:24,795
Das Gleiche mit Promo-Router.

482
00:35:24,795 --> 00:35:38,652
Lassen Sie mich, fordern Sie die Authentifizierung

483
00:35:38,652 --> 00:35:43,570
und dann für die Route get ist offen,

484
00:35:43,570 --> 00:35:47,109
POST wird gesteuert, Put wird gesteuert,

485
00:35:47,109 --> 00:35:50,790
Löschen wird gesteuert, dasselbe für die Promorouter/PromoID.

486
00:35:50,790 --> 00:35:54,460
Get ist offen, POST wird gesteuert,

487
00:35:54,460 --> 00:35:58,395
setzen und löschen werden ebenfalls gesteuert, das ist es.

488
00:35:58,395 --> 00:36:00,225
Speichern wir alle Änderungen.

489
00:36:00,225 --> 00:36:02,660
Sobald wir alle Änderungen abgeschlossen haben,

490
00:36:02,660 --> 00:36:04,185
speichern wir die Änderungen.

491
00:36:04,185 --> 00:36:08,270
Jetzt ist unsere Anwendung bereit, getestet zu werden.

492
00:36:08,270 --> 00:36:11,485
Also, lassen Sie uns gehen und unseren Server neu starten,

493
00:36:11,485 --> 00:36:14,885
oder wenn der Server nicht läuft,

494
00:36:14,885 --> 00:36:16,590
starten wir einfach den Server.

495
00:36:16,590 --> 00:36:18,770
Wenn ich zum Terminal gehe,

496
00:36:18,770 --> 00:36:20,040
läuft mein Server nicht.

497
00:36:20,040 --> 00:36:23,930
Also, lassen Sie mich den Server starten, indem Sie npm start eingeben.

498
00:36:24,620 --> 00:36:28,935
Interessanterweise hat es hier nur einen Fehler ausgelöst,

499
00:36:28,935 --> 00:36:32,330
ich wollte Ihnen nur zeigen, dass selbst ich Fehler machen kann,

500
00:36:32,330 --> 00:36:34,840
also werden Sie sehen, dass es hier einen Fehler gibt, der sagt:

501
00:36:34,840 --> 00:36:40,275
„Kann module.authenticate nicht finden“, und wenn ich dann den Code durchschaue,

502
00:36:40,275 --> 00:36:45,255
finde ich, dass dieses Problem in der,

503
00:36:45,255 --> 00:36:46,850
wo ist es vorgekommen?

504
00:36:46,850 --> 00:36:48,350
Also, ich suche einfach hier,

505
00:36:48,350 --> 00:36:50,020
und dann irgendwo hier unten,

506
00:36:50,020 --> 00:36:56,130
bemerkte ich, dass dieses Problem in meiner users.js Datei aufgetreten ist.

507
00:36:56,130 --> 00:36:57,870
Also, genau dort, heißt es,

508
00:36:57,870 --> 00:37:00,355
das ist in der Datei users.js.

509
00:37:00,355 --> 00:37:09,015
Also, gehen Sie in die Datei users.js, lassen Sie uns das beheben.

510
00:37:09,015 --> 00:37:14,285
Wenn ich zur Datei users.js gehe, genau an der Spitze, als ich mich authentifizieren musste, sagte ich:

511
00:37:14,285 --> 00:37:17,555
„.authenticate“, und wie ich Ihnen sagte,

512
00:37:17,555 --> 00:37:21,200
sollte das ein Punktpunkt sein, weil es im oberen Ordner ist.

513
00:37:21,200 --> 00:37:25,905
Diese Datei users.js im Ordner Routes

514
00:37:25,905 --> 00:37:31,985
und authentifizieren befindet sich im Ordner Projects Route, also sollte dies Punktauthentifizierung sein.

515
00:37:31,985 --> 00:37:34,660
Wenn du also Fehler machst, da gehst du,

516
00:37:34,660 --> 00:37:40,450
so wirst du an den Fehler erinnert, den du eingeführt hast.

517
00:37:40,450 --> 00:37:44,540
Also, speichern wir die Änderungen und starten Sie dann unseren Server neu.

518
00:37:44,540 --> 00:37:47,795
Wieder, zurück zu diesem Terminal,

519
00:37:47,795 --> 00:37:54,735
lassen Sie mich meinen Server starten und mein Server ist jetzt betriebsbereit,

520
00:37:54,735 --> 00:38:00,235
gehen wir zu Postman und testen Sie dann unsere Anwendung.

521
00:38:00,235 --> 00:38:04,695
Nun, in Postman, lassen Sie mich zuerst versuchen,

522
00:38:04,695 --> 00:38:11,170
ein GET auf localhost zu tun: 3000/Gerichte und dann, wenn ich ein GET mache,

523
00:38:11,170 --> 00:38:15,620
ist es erfolgreich, weil der GET-Endpunkt nicht gesteuert wird.

524
00:38:15,620 --> 00:38:18,595
So kann ich ein GET auf Geschirr

525
00:38:18,595 --> 00:38:23,545
machen, ich kann ein GET auf Promotionen machen,

526
00:38:23,545 --> 00:38:25,420
und es funktioniert alles gut.

527
00:38:25,420 --> 00:38:28,300
Aber wenn ich versuche, einen POST auf Geschirr zu machen,

528
00:38:28,300 --> 00:38:32,435
so lassen Sie mich finden, wo ich einen POST auf Geschirr gemacht habe.

529
00:38:32,435 --> 00:38:35,245
Hier habe ich einen POST auf Geschirr gemacht.

530
00:38:35,245 --> 00:38:38,030
Also, als ich versuchte, einen POST auf Geschirr zu machen,

531
00:38:38,030 --> 00:38:40,540
sagt es sofort unbefugt.

532
00:38:40,540 --> 00:38:47,410
Also hat mein Passport-Modul erkannt, dass ich nicht autorisiert bin,

533
00:38:47,410 --> 00:38:49,825
also darf ich dies nicht tun, also daran erinnert es mich.

534
00:38:49,825 --> 00:38:52,750
Lassen Sie mich die Cookies von löschen,

535
00:38:52,750 --> 00:38:57,980
falls Sie ein Cookie in Ihrem Postman finden, entfernen Sie einfach das Cookie,

536
00:38:57,980 --> 00:39:00,410
das dem localhost entspricht

537
00:39:00,410 --> 00:39:03,815
, weil dieses Cookie nicht mehr benötigt wird und nicht benötigt wird.

538
00:39:03,815 --> 00:39:06,100
Also, selbst wenn ich das Cookie und dann POST entferne,

539
00:39:06,100 --> 00:39:07,990
wird es immer noch nicht autorisiert sagen.

540
00:39:07,990 --> 00:39:11,715
Also, ich bin nicht befugt, diese Operationen durchzuführen.

541
00:39:11,715 --> 00:39:13,305
Also, ich muss mich einloggen.

542
00:39:13,305 --> 00:39:15,430
Wenn Sie nun die vorherige Übung durchgeführt haben,

543
00:39:15,430 --> 00:39:19,390
hätten Sie den Benutzer verlassen, den Sie zuvor angemeldet haben.

544
00:39:19,390 --> 00:39:25,865
Zum Beispiel hätten Sie diesen bestimmten Benutzer in der vorherigen Übung angemeldet,

545
00:39:25,865 --> 00:39:29,530
lassen Sie mich versuchen, denselben Benutzer erneut anzumelden und

546
00:39:29,530 --> 00:39:36,090
mein Server sollte sich beklagen, dass userExistsError sagt, so dass der Benutzer existiert,

547
00:39:36,090 --> 00:39:38,455
also muss ich mich nicht erneut anmelden.

548
00:39:38,455 --> 00:39:42,290
Wenn Sie den Benutzer aus Ihrer MongoDB gelöscht haben,

549
00:39:42,290 --> 00:39:47,275
melden Sie sich einfach noch einmal an und lassen Sie uns dann einloggen.

550
00:39:47,275 --> 00:39:55,830
Also senden wir eine Login-Anfrage an diesen Endpunkt.

551
00:39:55,830 --> 00:40:00,640
Wenn ich also die Anmeldeanforderung durch einen POST an den Endbenutzer sende,

552
00:40:00,640 --> 00:40:03,365
beachten Sie, was von meinem Server zurückgegeben wird.

553
00:40:03,365 --> 00:40:06,965
Sie bemerken sofort, dass Sie in der Antwortnachricht

554
00:40:06,965 --> 00:40:10,830
zusammen mit dem Erfolgsflag und der Statusmeldung

555
00:40:10,830 --> 00:40:13,740
auch hier ein Token erhalten.

556
00:40:13,740 --> 00:40:16,365
Nun, dieses spezielle Token,

557
00:40:16,365 --> 00:40:17,960
muss ich dieses Token kopieren,

558
00:40:17,960 --> 00:40:21,045
denn in meinen nachfolgenden Anfragen

559
00:40:21,045 --> 00:40:23,535
muss ich dieses Token enthalten.

560
00:40:23,535 --> 00:40:31,610
Also, lassen Sie mich zu der rohen Version davon gehen und dass ich dieses Token kopieren werde.

561
00:40:31,610 --> 00:40:33,875
Dieses Token ist nichts anderes als eine lange Zeichenfolge,

562
00:40:33,875 --> 00:40:36,260
also lassen Sie mich dieses Token kopieren.

563
00:40:36,260 --> 00:40:41,765
Wenn Sie nun neugierig sind, was in diesem Token enthalten ist,

564
00:40:41,765 --> 00:40:44,800
kann das JSON Web Token untersucht werden.

565
00:40:44,800 --> 00:40:48,140
Es gibt eine bestimmte Website, auf der Sie

566
00:40:48,140 --> 00:40:52,235
Ihr JSON-Web-Token eingeben und dann tatsächlich überprüfen können, was sich innerhalb des JSON-Web-Token befindet.

567
00:40:52,235 --> 00:40:56,685
Machen wir das als nächsten Schritt.

568
00:40:56,685 --> 00:41:05,565
Geben Sie in einem Browserfenster einfach jwt.io ein und dies führt Sie zu dieser Website namens JSON Web Token jwt.io.

569
00:41:05,565 --> 00:41:07,590
Wenn Sie sich erinnern,

570
00:41:07,590 --> 00:41:10,685
hatte ich Ihnen in der Vorlesung die Struktur des JSON Web Token gezeigt

571
00:41:10,685 --> 00:41:14,290
und Ihnen gezeigt, dass das JSON Web Token drei Teile enthält: den Header,

572
00:41:14,290 --> 00:41:18,040
die Nutzlast und die Informationen dort.

573
00:41:18,040 --> 00:41:19,730
Nun, in diesem Fall sind

574
00:41:19,730 --> 00:41:25,880
die Informationen hier oben, also werde ich

575
00:41:25,880 --> 00:41:33,285
mein JSON Web Token in diese linke Seite

576
00:41:33,285 --> 00:41:37,270
einfügen, also lassen Sie mich das auswählen und dann mein JSON Web Token

577
00:41:37,270 --> 00:41:41,920
in die linke Seite im kodierten Teil einfügen und dann auf der rechten Seite

578
00:41:41,920 --> 00:41:46,030
zeigt es Ihnen genau, was ist innerhalb des JSON-Web-Token, das ich gerade erstellt habe.

579
00:41:46,030 --> 00:41:49,580
Es sagt also, dass der Header diese beiden Informationen enthält.

580
00:41:49,580 --> 00:41:54,090
Die Payload beachten Sie, dass es die ID

581
00:41:54,090 --> 00:41:59,245
des Benutzers und dann die Signatur unten hier enthält.

582
00:41:59,245 --> 00:42:03,995
Also, das ist, was in meinem JSON Web Token enthalten ist.

583
00:42:03,995 --> 00:42:07,005
Zurück zu Postman,

584
00:42:07,005 --> 00:42:12,110
lassen Sie mich jetzt versuchen, das Geschirr zu bekommen.

585
00:42:12,110 --> 00:42:15,940
Also, wenn ich GET localhost: 3000/Gerichte sage,

586
00:42:15,940 --> 00:42:18,650
wird es immer noch eine leere Zeichenfolge,

587
00:42:18,650 --> 00:42:23,385
leeres Array hier zurückgeben, weil meine Datenbank es nicht enthält.

588
00:42:23,385 --> 00:42:29,635
Also, lassen Sie mich ein Gericht in meine Datenbank posten.

589
00:42:29,635 --> 00:42:33,290
Also, ich werde die POST-Operation wählen und im Körper

590
00:42:33,290 --> 00:42:36,095
sehen Sie, dass ich mein Gericht hier habe.

591
00:42:36,095 --> 00:42:41,215
In der Kopfzeile werde ich den neuen Header namens

592
00:42:41,215 --> 00:42:47,240
Autorisierung hinzufügen und Sie erinnern sich, dass

593
00:42:47,240 --> 00:42:53,425
Sie früher für die grundlegende Autorisierung Basic sagten und dann die Base 64-codierte Zeichenfolge dort hatten.

594
00:42:53,425 --> 00:42:58,970
Wenn Sie Ihr JSON Web Token in den Autorisierungs-Header aufnehmen möchten,

595
00:42:58,970 --> 00:43:01,150
da

596
00:43:01,150 --> 00:43:04,550
wir in unserem Code die Autorisierung als Bearer-Token sagten.

597
00:43:04,550 --> 00:43:08,040
Also, wenn Sie das Token in den Autorisierungskopf aufnehmen möchten,

598
00:43:08,040 --> 00:43:13,275
sagen wir in der Autorisierung Bearer und dann fügen wir diese

599
00:43:13,275 --> 00:43:19,080
Token-Zeichenfolge ein, die wir gerade von unserer eingehenden Anfrage kopiert haben.

600
00:43:19,080 --> 00:43:21,935
Also fügen wir die Token-Zeichenfolge dort ein.

601
00:43:21,935 --> 00:43:24,360
Also, das ist, was im

602
00:43:24,360 --> 00:43:29,795
Autorisierungskopf meiner ausgehenden Anfrage hier enthalten sein wird,

603
00:43:29,795 --> 00:43:33,845
ausgehende POST-Anforderung hier.

604
00:43:33,845 --> 00:43:39,970
Beachten Sie also, dass die linke Seite Bearer sagt und die rechte Seite ist die Zeichenfolge,

605
00:43:39,970 --> 00:43:43,230
das Token, das ich gerade von

606
00:43:43,230 --> 00:43:48,460
dem Punkt kopiert habe, an dem ich mich angemeldet habe, und dann lasse ich die POST-Nachricht

607
00:43:48,460 --> 00:43:57,590
jetzt senden und mein POST ist jetzt erfolgreich und dies wird in meine Datenbank geschrieben.

608
00:43:57,590 --> 00:44:01,115
Nun, wenn Sie sicher sein möchten, dass es gepostet wurde,

609
00:44:01,115 --> 00:44:04,555
lassen Sie uns ein GET machen und wenn Sie ein GET machen,

610
00:44:04,555 --> 00:44:12,935
können Sie sehen, dass tatsächlich dieses Gericht in meine Datenbank eingefügt wurde, wie hier gezeigt.

611
00:44:12,935 --> 00:44:19,260
So werden Sie JSON-Web-Token in Ihrer Anwendung verwenden.

612
00:44:19,260 --> 00:44:22,230
Wenn Sie also einen POST-, PUT-

613
00:44:22,230 --> 00:44:25,505
oder einen DELETE-Vorgang auf einem der Endpunkte ausführen müssen,

614
00:44:25,505 --> 00:44:27,010
würden Sie einschließen.

615
00:44:27,010 --> 00:44:33,895
Also, lassen Sie mich zurück zu dieser POST-Anforderung hier.

616
00:44:33,895 --> 00:44:35,890
In der Kopfzeile werden Sie

617
00:44:35,890 --> 00:44:41,540
dieses Autorisierungsfeld setzen und dann würde dies in der Autorisierung enthalten sein,

618
00:44:41,540 --> 00:44:47,540
Sie starten es mit Bearer und dann die Token-Zeichenfolge,

619
00:44:47,540 --> 00:44:50,200
nach diesem Bearer-Leerzeichen,

620
00:44:50,200 --> 00:44:54,215
ein einzelnes Leerzeichen und dann die Token-Zeichenfolge, die darauf folgt.

621
00:44:54,215 --> 00:44:58,310
So würden Ihre Anforderungsnachrichten

622
00:44:58,310 --> 00:45:03,140
das JSON Web Token in der Kopfzeile der ausgehenden Anforderungsnachricht tragen.

623
00:45:03,140 --> 00:45:08,220
Sie können das Token auch in den Textkörper der ausgehenden Anforderungsnachricht einschließen.

624
00:45:08,220 --> 00:45:10,310
Nun, dafür müssen Sie

625
00:45:10,310 --> 00:45:18,210
Ihren Express-Server konfigurieren, besonders das zusätzliche JWT in der

626
00:45:18,210 --> 00:45:21,120
Datei authenticate.js, um es aus

627
00:45:21,120 --> 00:45:24,455
dem Körper zu akzeptieren, so dass Sie sich daran erinnern, dass wir dort gesehen haben, dass

628
00:45:24,455 --> 00:45:28,890
das zusätzliche JWT viele verschiedene Möglichkeiten unterstützt,

629
00:45:28,890 --> 00:45:33,695
das JSON Web Token aus dem eingehenden -Anfrage.

630
00:45:33,695 --> 00:45:35,090
Also, dort müssen Sie angeben,

631
00:45:35,090 --> 00:45:36,670
wenn Sie es in den Körper aufnehmen wollen,

632
00:45:36,670 --> 00:45:39,115
müssen Sie diese Informationen dort angeben.

633
00:45:39,115 --> 00:45:42,395
Nun, die Details dazu, wie Sie das tun können, können Sie

634
00:45:42,395 --> 00:45:49,885
die Passport JWT Modul-Dokumentation, um zu verstehen, wie dies geschieht.

635
00:45:49,885 --> 00:45:54,610
In diesem Kurs werde ich das einfach im Autorisierungs-Header verwenden,

636
00:45:54,610 --> 00:45:59,835
wie ich hier gezeigt habe, und das funktioniert für die meisten Fälle gut.

637
00:45:59,835 --> 00:46:02,620
Wenn Sie nun eine Web-App, eine

638
00:46:02,620 --> 00:46:06,635
Angular-App oder eine Ionic oder NativeScript-App entwickeln,

639
00:46:06,635 --> 00:46:09,800
müssen Sie in der Lage sein,

640
00:46:09,800 --> 00:46:16,615
diese App zu konfigurieren, wobei das JSON Web Token in den Autorisierungsheader aufgenommen wird.

641
00:46:16,615 --> 00:46:22,215
In der letzten Lektion dieses Kurses

642
00:46:22,215 --> 00:46:26,255
werde ich Ihnen zeigen, wie Sie den Client und den Server, den Client,

643
00:46:26,255 --> 00:46:29,310
den Sie in den vorherigen Kursen entwickelt haben, mit

644
00:46:29,310 --> 00:46:32,495
dem Server integrieren, den wir in diesem Kurs entwickelt haben.

645
00:46:32,495 --> 00:46:35,120
Damit schließen wir diese Übung ab.

646
00:46:35,120 --> 00:46:37,940
In dieser Übung haben wir gesehen, wie wir

647
00:46:37,940 --> 00:46:42,200
unsere Anwendung für die Verwendung von JSON Web Token konfigurieren können,

648
00:46:42,200 --> 00:46:50,555
und wir haben gesehen, wie wir die Authentifizierung des Benutzers mit dem JSON Web Token umgehen,

649
00:46:50,555 --> 00:46:55,555
indem wir die Unterstützung des Passport-Moduls und des Passport JWT Moduls

650
00:46:55,555 --> 00:46:58,605
und der JSON Web Token Node Module verwenden.

651
00:46:58,605 --> 00:47:01,090
Damit schließen wir diese Übung ab.

652
00:47:01,090 --> 00:47:09,110
Dies ist ein guter Zeitpunkt für Sie, ein Git Commit mit der Nachricht Passport JWT zu tun.