1
00:00:00,000 --> 00:00:05,021
[MUSIC]

2
00:00:05,021 --> 00:00:09,395
Nun, da wir die Notwendigkeit einer grundlegenden Authentifizierung in unserer

3
00:00:09,395 --> 00:00:14,383
Express-Anwendung verstanden haben, fahren wir mit der Übung fort, in der wir dem

4
00:00:14,383 --> 00:00:19,372
ConFusion-Server, den wir bisher entwickelt haben,

5
00:00:19,372 --> 00:00:21,311
dem Express REST API-Server, die grundlegende Authentifizierung hinzufügen.

6
00:00:22,470 --> 00:00:24,050
Wir werden auf dem Weg

7
00:00:24,050 --> 00:00:29,170
lernen, wie wir die grundlegende Authentifizierung innerhalb unseres Servers verwenden können.

8
00:00:29,170 --> 00:00:34,811
Und dann in den nachfolgenden Übungen werden wir diese Idee weiter erweitern,

9
00:00:34,811 --> 00:00:41,107
um einen vollwertigen Authentifizierungsdienst für unseren Express REST API-Server hinzuzufügen.

10
00:00:42,965 --> 00:00:46,576
In dieser Übung gehen wir zum ConFusion-Server,

11
00:00:46,576 --> 00:00:49,290
woran wir bisher gearbeitet haben.

12
00:00:49,290 --> 00:00:54,333
Sie müssen also die Umsetzung des zweiten Auftrags bereits abgeschlossen

13
00:00:54,333 --> 00:00:59,553
haben, wo Sie die Promotions und das Leaders-Modell entwickelt hätten.

14
00:00:59,553 --> 00:01:04,289
Außerdem wurden die Routen für den Leader Router und

15
00:01:04,289 --> 00:01:09,470
den Promo-Router in Ihrer ConFusion Server-Anwendung aktualisiert.

16
00:01:09,470 --> 00:01:12,960
In diesem Code gehen wir also zu app.js und

17
00:01:12,960 --> 00:01:17,392
fügen Sie dann die grundlegende Authentifizierung in app.js hinzu.

18
00:01:17,392 --> 00:01:22,290
Also in app.js, wie wir über die Art und Weise verstanden haben, wie

19
00:01:22,290 --> 00:01:26,970
der mittlere Weg es in Express-Anwendung funktioniert.

20
00:01:26,970 --> 00:01:31,010
Also beginnen wir hier in der app.js,

21
00:01:31,010 --> 00:01:36,640
indem wir hier alle verschiedenen Knotenmodule importieren.

22
00:01:36,640 --> 00:01:42,650
Und danach beginnen wir hier, indem wir zuerst app.use logger dev sagen.

23
00:01:42,650 --> 00:01:46,410
All diese werden also auf unsere Anwendung angewendet werden.

24
00:01:46,410 --> 00:01:51,978
Und dann ist dieser Aufruf hier app.use (express.static),

25
00:01:51,978 --> 00:01:58,128
was es uns ermöglicht, statische Daten aus dem öffentlichen Ordner zu liefern.

26
00:01:58,128 --> 00:02:03,068
Jetzt wollen sie die Authentifizierung durchführen, bevor wir

27
00:02:03,068 --> 00:02:08,870
dem Client erlauben, Daten von unserem Server abzurufen.

28
00:02:08,870 --> 00:02:14,570
Also genau dort werden wir hineingehen und ein Authentifizierungs-Badge hinzufügen.

29
00:02:14,570 --> 00:02:18,090
So bemerken Sie, dass alles, was danach kommt,

30
00:02:18,090 --> 00:02:22,970
all die Middleware, die montiert ist und nach diesem bestimmten Punkt kommt.

31
00:02:22,970 --> 00:02:27,070
Wir müssen die Autorisierungsphase durchlaufen

32
00:02:27,070 --> 00:02:29,550
, bevor diese Middleware Zugriff haben kann.

33
00:02:29,550 --> 00:02:34,709
Also genau dort werde ich in app.use hinzufügen und

34
00:02:34,709 --> 00:02:41,600
dann eine Funktion namens auth hinzufügen, die ich jetzt implementieren werde.

35
00:02:41,600 --> 00:02:46,180
Also, indem wir dies tun, was wir angeben, ist die Standardeinstellung,

36
00:02:46,180 --> 00:02:50,200
der Client kann auf alle dieser zugreifen,

37
00:02:50,200 --> 00:02:56,070
entweder auf ihre statischen Ressourcen im Öffentlichen Ordner, oder

38
00:02:56,070 --> 00:03:00,140
auf eine der Ressourcen, Gerichte, Aktionen, oder Führer oder sogar Benutzer, wie wir später sehen werden.

39
00:03:02,150 --> 00:03:05,700
Der Kunde muss zuerst autorisiert werden.

40
00:03:05,700 --> 00:03:08,220
Also, genau dort, werden wir in der Auth hinzufügen.

41
00:03:08,220 --> 00:03:15,960
Also lassen Sie mich die Funktion hier auth direkt dort hinzufügen.

42
00:03:15,960 --> 00:03:19,849
Und dann verwenden Sie es sofort innerhalb unserer

43
00:03:19,849 --> 00:03:23,147
Express-Anwendung als Middleware dort.

44
00:03:23,147 --> 00:03:27,826
Diese Funktion, auth wird also drei Parameter annehmen,

45
00:03:27,826 --> 00:03:33,914
das Anforderungsobjekt, das Ressourcenobjekt und das nächste Objekt, ja.

46
00:03:37,015 --> 00:03:41,830
Lassen Sie mich also innerhalb dieser Funktion

47
00:03:41,830 --> 00:03:48,605
zuerst wissen, was im Anfrage-Header enthalten ist.

48
00:03:50,265 --> 00:03:56,175
Lassen Sie mich einfach die Request-Header dort protokollieren, nur um Ihnen zu demonstrieren,

49
00:03:56,175 --> 00:03:59,970
denn sobald Sie den Autorisierungs-Header hinzufügen,

50
00:03:59,970 --> 00:04:03,390
möchten wir ihn direkt dort sehen können.

51
00:04:03,390 --> 00:04:07,390
Also werden wir zuerst ein Konsolenprotokoll machen,

52
00:04:07,390 --> 00:04:10,142
nur um zu sehen, was von der Client-Seite kommt.

53
00:04:10,142 --> 00:04:14,379
Dann lassen Sie mich ihren

54
00:04:14,379 --> 00:04:20,401
Autorisierungs-Header erhalten, indem Sie

55
00:04:20,401 --> 00:04:26,900
req.headers .authorisierung sagen.

56
00:04:26,900 --> 00:04:31,120
Hier bekommen wir den Autorisierungs-Header, der

57
00:04:31,120 --> 00:04:33,320
von unserer Client-Seite hinzugefügt wird.

58
00:04:33,320 --> 00:04:37,830
Wenn es nicht da ist, dann müssen wir natürlich entsprechend handeln.

59
00:04:37,830 --> 00:04:44,493
Wenn also der AuthHeader null ist,

60
00:04:44,493 --> 00:04:48,992
was bedeutet, dass es in unserer eingehenden

61
00:04:48,992 --> 00:04:53,653
Anfrage keinen Authentifizierungsheader gibt, dann hat unser Client offensichtlich nicht den Benutzernamen und das

62
00:04:53,653 --> 00:04:56,650
Passwort in den Authentifizierungsheader aufgenommen.

63
00:04:56,650 --> 00:05:01,230
Daher müssen wir unseren Kunden herausfordern, diese Informationen zu liefern.

64
00:05:01,230 --> 00:05:06,338
Also, wenn der Autorisierungs-Header null ist, dann werden wir sehen,

65
00:05:06,338 --> 00:05:12,130
var irr neuen Fehler,

66
00:05:12,130 --> 00:05:19,140
so dass wir nicht zulassen, dass unsere Client-Anfrage weiter über diesen Punkt hinaus geht.

67
00:05:19,140 --> 00:05:23,803
Also werden wir sagen, Sie sind nicht authentifiziert,

68
00:05:23,803 --> 00:05:28,222
und dann werden wir Kunden dort herausfordern.

69
00:05:28,222 --> 00:05:33,196
Wir werden also res.setHeader sagen, also

70
00:05:33,196 --> 00:05:38,684
werden wir den Header in der

71
00:05:38,684 --> 00:05:46,061
Antwortnachricht setzen, die WWW-Authenticate sagt,

72
00:05:46,061 --> 00:05:50,520
und aus der Vorlesung früher

73
00:05:50,520 --> 00:05:55,493
werden Sie sehen, warum wir dies

74
00:05:55,493 --> 00:06:00,120
in den Antwort-Header einfügen.

75
00:06:00,120 --> 00:06:04,480
Und dann werden wir sagen, err status.401.

76
00:06:04,480 --> 00:06:07,710
401 ist nicht autorisierter Zugriff.

77
00:06:07,710 --> 00:06:12,740
Und dann werden wir einfach unseren Aufruf als nächstes mit dem Header generieren.

78
00:06:12,740 --> 00:06:17,960
Das bedeutet, dass es all dies überspringt und zum Fehlerhandler wechselt,

79
00:06:17,960 --> 00:06:20,710
wo der Fehlerbehandler die Antwortnachricht konstruiert und

80
00:06:20,710 --> 00:06:25,880
dort an meinen Client zurücksendet.

81
00:06:25,880 --> 00:06:31,290
Also, wenn der Client den Authentifizierungsheader oder

82
00:06:31,290 --> 00:06:34,690
den Autorisierungs-Header nicht enthalten hat, werde ich den Client herausfordern,

83
00:06:34,690 --> 00:06:38,980
ihn zu bitten, mir den Autorisierungs-Header dort bereitzustellen.

84
00:06:38,980 --> 00:06:45,570
Wenn nicht, dann weiß ich, dass der Autorisierungs-Header existiert.

85
00:06:45,570 --> 00:06:51,553
Über diesen Punkt hinaus werden wir var auth sagen,

86
00:06:51,553 --> 00:06:55,760
und ich werde den Autorisierungs-Header extrahieren.

87
00:06:57,460 --> 00:07:02,880
Und da der AuthHeader eine Zeichenfolge ist,

88
00:07:02,880 --> 00:07:07,650
werde ich diesen Wert und

89
00:07:07,650 --> 00:07:12,690
diesen Autorisierungs-Header teilen, werde ich den Wert aufteilen.

90
00:07:12,690 --> 00:07:17,350
Wie Sie sehen können, ermöglicht der Puffer Ihnen, den Wert zu teilen und

91
00:07:17,350 --> 00:07:23,805
dann geben wir auch die Codierung des Puffers, der Base64-Codierung hier ist.

92
00:07:23,805 --> 00:07:28,790
Also werden wir das in einen Puffer konvertieren, indem wir diesen in zwei Teile teilen und

93
00:07:30,250 --> 00:07:32,390
den Raum als Splitting Teil verwenden.

94
00:07:32,390 --> 00:07:37,614
Wenn Sie sich also den Autorisierungs-Header anschauten, haben Sie gesehen, warum

95
00:07:37,614 --> 00:07:42,656
der Leerraum den Wert „basic“ trennt, und dann gibt es Ihnen

96
00:07:42,656 --> 00:07:48,172
den Rest der Base64-codierten Zeichenfolge, die den Benutzernamen und das Passwort enthält.

97
00:07:48,172 --> 00:07:53,510
Und daraus möchten wir den Benutzernamen und das Passwort extrahieren.

98
00:07:53,510 --> 00:07:59,970
Also werden wir diesen Wert teilen, und dann werden wir nur berücksichtigen,

99
00:07:59,970 --> 00:08:07,510
wenn Sie die Zeichenfolge teilen, indem Sie dies verwenden, wird es das in ein Array aufteilen.

100
00:08:07,510 --> 00:08:11,780
Und das erste Element des Arrays enthält Basic.

101
00:08:11,780 --> 00:08:17,370
Das zweite Element des Arrays ist, wo diese base64-codierte Zeichenfolge vorhanden ist.

102
00:08:17,370 --> 00:08:21,280
Deshalb schauen wir uns nur das zweite Element dieses Arrays an.

103
00:08:21,280 --> 00:08:27,800
Diese Aufteilung bewirkt also, dass die Zeichenfolge in ein Array von zwei Elementen aufgeteilt wird.

104
00:08:27,800 --> 00:08:32,944
Also könnten wir, wir nehmen die base64-codierte Zeichenfolge davon auf.

105
00:08:32,944 --> 00:08:39,820
Und dann werden wir in diesen Puffer, und dann werden wir das in String konvertieren.

106
00:08:39,820 --> 00:08:45,830
Und dann noch einmal, teilen Sie die Zeichenfolge noch einmal, da die Zeichenfolge

107
00:08:45,830 --> 00:08:51,200
selbst den Benutzernamen und das Kennwort enthält, getrennt durch einen Doppelpunkt.

108
00:08:51,200 --> 00:08:56,040
Also, ich werde es mit dem Doppelpunkt als

109
00:08:56,040 --> 00:09:01,350
Aufteilungspunkt für diese Zeichenfolge hier teilen.

110
00:09:01,350 --> 00:09:05,727
Beachten Sie also, dass ich hier zwei Splits lade, eine auf das Leerzeichen und

111
00:09:05,727 --> 00:09:11,110
die zweite, mit dem Doppelpunkt, der den Benutzernamen und das Passwort trennt.

112
00:09:11,110 --> 00:09:18,570
Am Ende dieser Variablen auth sollte also ein Array sein, das zwei Elemente enthält,

113
00:09:18,570 --> 00:09:24,460
den Benutzernamen und das Passwort, das aus der base64-Zeichenfolge extrahiert wird.

114
00:09:24,460 --> 00:09:31,744
Also an diesem Punkt, was ich tun werde, ist,

115
00:09:31,744 --> 00:09:35,908
nur zu Ihrer Klarheit,

116
00:09:35,908 --> 00:09:40,695
werde ich einfach var

117
00:09:40,695 --> 00:09:46,733
username = auth [0] sagen und dann

118
00:09:46,733 --> 00:09:51,970
var password = auth [1].

119
00:09:51,970 --> 00:09:57,760
Jetzt habe ich den Benutzernamen und das Passwort aus meinem Autorisierungs-Header extrahiert.

120
00:09:57,760 --> 00:10:02,210
Jetzt werde ich einen Standardwert für den Benutzernamen und das

121
00:10:02,210 --> 00:10:06,030
Passwort in dieser Implementierung verwenden.

122
00:10:06,030 --> 00:10:10,950
Später werden wir sehen, dass wir den Benutzern erlauben können, ihren eigenen Benutzernamen und ihr

123
00:10:10,950 --> 00:10:11,530
Passwort zu erstellen.

124
00:10:11,530 --> 00:10:14,304
Aber im Moment werde ich nur verwenden,

125
00:10:17,358 --> 00:10:20,925
Der codierte Benutzername und Passwort als Admin.

126
00:10:23,615 --> 00:10:30,705
Und das Passwort wird nur Passwort sein.

127
00:10:30,705 --> 00:10:32,778
Für diese grundlegende Übung

128
00:10:32,778 --> 00:10:37,970
verwenden wir dies als Standard-Benutzername und Passwort.

129
00:10:39,468 --> 00:10:47,520
Wenn der Benutzername, den ich erhalte, admin ist und das Passwort das String-Passwort ist.

130
00:10:47,520 --> 00:10:52,490
Dann bin ich alles in Ordnung zu erlauben, dass die

131
00:10:52,490 --> 00:10:56,950
Client-Anfrage an die nächste Middleware weitergegeben wird, also werde ich als nächstes sagen.

132
00:10:56,950 --> 00:11:01,130
Also, wenn ich als nächstes sage, bedeutet dies, dass von der Authentifizierung

133
00:11:01,130 --> 00:11:05,840
ihre Anfrage den nächsten Satz von Middleware hier weitergegeben wird und

134
00:11:05,840 --> 00:11:10,660
Express dann versuchen wird, die spezifische Anfrage zu entsprechen, um

135
00:11:11,830 --> 00:11:15,420
bestimmte Middleware zu sein, die diese Anfrage bearbeitet.

136
00:11:15,420 --> 00:11:19,440
Das ist also, wo wir zulassen, dass es durchgeht.

137
00:11:19,440 --> 00:11:24,000
Wenn nicht, bedeutet das, dass der Benutzername und

138
00:11:24,000 --> 00:11:29,260
das Passwort nicht mit der Anfrage,

139
00:11:29,260 --> 00:11:33,010
dem Standard-Benutzernamen und dem Passwort übereinstimmen, die ich einrichte.

140
00:11:33,010 --> 00:11:34,930
Das bedeutet also, dass es einen Fehler gibt.

141
00:11:34,930 --> 00:11:39,310
Also in diesem Fall werde ich hier wieder einen Fehler verursachen,

142
00:11:39,310 --> 00:11:43,280
also sagen wir sonst, Fehler.

143
00:11:43,280 --> 00:11:49,540
Wir werden also wieder einen Fehler generieren und dann den Client auffordern,

144
00:11:49,540 --> 00:11:55,430
hier die richtigen Autorisierungsinformationen, den Benutzernamen und das Passwort einzugeben.

145
00:11:55,430 --> 00:11:56,730
Das war's also.

146
00:11:56,730 --> 00:12:01,100
Dieses kleine bisschen Middleware, die wir gerade hier implementiert haben,

147
00:12:01,100 --> 00:12:04,010
Autorisierungs-Middleware, die wir gerade hier implementiert haben.

148
00:12:04,010 --> 00:12:08,840
Reicht aus, um die grundlegende Authentifizierung innerhalb der Out-Anwendung zu implementieren.

149
00:12:08,840 --> 00:12:10,300
Nachdem wir diese Änderungen vorgenommen haben,

150
00:12:10,300 --> 00:12:15,210
speichern wir die Änderungen und dann werden wir sehen, wie das tatsächlich in der Praxis funktioniert.

151
00:12:15,210 --> 00:12:16,770
Speichern wir die Änderungen.

152
00:12:16,770 --> 00:12:20,600
Und dann starten wir unseren Server.

153
00:12:20,600 --> 00:12:22,980
Nun, gehen Sie zum Terminal, natürlich,

154
00:12:22,980 --> 00:12:26,916
stellen Sie sicher, dass Sie MongoDB-Server sind und läuft.

155
00:12:26,916 --> 00:12:34,390
Andernfalls wird der Express-Server nicht gestartet.

156
00:12:34,390 --> 00:12:38,350
Also habe ich die Eingabeaufforderung npm start eingeben, und

157
00:12:38,350 --> 00:12:41,810
dann wird Ihr Express-Server betriebsbereit sein.

158
00:12:41,810 --> 00:12:46,760
Öffnen Sie nun im Inkognito-Fenster in Ihrem Browser.

159
00:12:46,760 --> 00:12:51,280
Der Grund, warum ich Sie bitten, ein Inkognito-Fenster zu verwenden, ist, dass, wenn Sie

160
00:12:51,280 --> 00:12:55,820
den Benutzernamen und das Passwort eingeben, es von Ihrem Browser zwischengespeichert wird.

161
00:12:55,820 --> 00:12:59,490
Wenn Sie also ein Inkognito-Fenster verwenden, wenn Sie den Browser neu starten...

162
00:12:59,490 --> 00:13:01,710
Dann wird der Cache automatisch gelöscht,

163
00:13:01,710 --> 00:13:04,300
so dass diese Informationen nicht gespeichert werden.

164
00:13:04,300 --> 00:13:07,500
Was passiert nun, wenn Sie den Benutzernamen und das Kennwort eingeben, wird es zwischengespeichert.

165
00:13:07,500 --> 00:13:11,570
Wenn Sie also versuchen, auf den Server zuzugreifen,

166
00:13:11,570 --> 00:13:15,840
werden die zwischengespeicherten Informationen automatisch in der von Ihnen generierten Anfrage gesendet.

167
00:13:15,840 --> 00:13:18,710
Deshalb ist es wichtig,

168
00:13:18,710 --> 00:13:23,400
ein Inkognito-Fenster zu verwenden, nur um Ihnen zu zeigen, dass die grundlegende Authentifizierung funktioniert.

169
00:13:23,400 --> 00:13:31,140
Geben Sie also in der Adressleiste Ihres Browsers localhost:3000 ein und sehen Sie, was passiert.

170
00:13:31,140 --> 00:13:36,920
Wenn Sie also localhost:3000 eingeben, sehen Sie sofort, dass Ihr Browser

171
00:13:36,920 --> 00:13:43,290
diesen Dialog oben öffnet und Sie auffordert, den Benutzernamen und das Passwort einzugeben.

172
00:13:43,290 --> 00:13:50,240
Wenn Sie es nicht eingeben, lassen Sie mich einen zufälligen Benutzernamen eingeben und dann sehen, was passiert.

173
00:13:50,240 --> 00:13:54,000
Wenn ich also einen zufälligen Benutzernamen und ein Passwort eingebe,

174
00:13:54,000 --> 00:13:57,260
sehen Sie, dass die Anfrage abgelehnt wird.

175
00:13:57,260 --> 00:14:00,890
Ich darf nicht auf den Server zugreifen, und

176
00:14:00,890 --> 00:14:06,100
dann, wenn der Server wieder sagt, dass der Client nicht autorisiert ist.

177
00:14:06,100 --> 00:14:10,330
Und so wird es wieder kommen und uns wieder für die richtige Authentifizierung herausfordern.

178
00:14:10,330 --> 00:14:12,820
Lassen Sie mich also die aktuelle Authentifizierung eingeben.

179
00:14:12,820 --> 00:14:17,670
Also lassen Sie mich admin und das Passwort als Passwort eingeben.

180
00:14:17,670 --> 00:14:23,650
Und dann melden Sie sich an, und Sie werden sehen, dass jetzt die

181
00:14:23,650 --> 00:14:28,530
Express-Anwendung Ihnen erlaubt, auf den Standardwert zuzugreifen, der

182
00:14:28,530 --> 00:14:34,700
in diesem Fall die Datei Index.html aus diesem statischen öffentlichen Ordner ist.

183
00:14:34,700 --> 00:14:39,590
Nun, das gleiche, wenn Sie versuchen, auf localhost: Gerichte

184
00:14:39,590 --> 00:14:43,260
ohne die Autorisierung zuzugreifen, dann funktioniert es nicht.

185
00:14:43,260 --> 00:14:49,320
Und ich werde Ihnen das in einer Minute mit dem Postboten zeigen.

186
00:14:50,630 --> 00:14:56,011
Nachdem wir nun gesehen haben, wie die Authentifizierung funktioniert,

187
00:14:56,011 --> 00:15:00,985
schauen wir uns an, was auf der Konsole auf unserer Serverseite passiert ist. Wenn Sie

188
00:15:06,181 --> 00:15:11,141
zur Konsole auf unserer Serverseite gehen, sehen Sie, dass

189
00:15:11,141 --> 00:15:13,769
hier eine ganze Reihe von Informationen ausgedruckt wurde, so wie Sie gesehen

190
00:15:13,769 --> 00:15:17,030
haben, haben wir die Anforderungskopfzeilen hier abgemeldet.

191
00:15:17,030 --> 00:15:21,040
Dies ist also die erste Anfrage, die mit dem Anforderungsheader einging.

192
00:15:21,040 --> 00:15:26,860
Und hier sehen Sie, dass es keinen Autorisierungsheader in der Anfrage gibt.

193
00:15:26,860 --> 00:15:34,620
Und so hat Ihr Server das abgelehnt, mit einer 401 bat unseren Client, sich selbst zu autorisieren.

194
00:15:34,620 --> 00:15:40,240
Das zweite Mal auch, da wir nicht in die richtige Autorisierung eingegeben haben, dass der

195
00:15:40,240 --> 00:15:41,916
Server abgelehnt.

196
00:15:41,916 --> 00:15:48,390
Natürlich bemerken Sie jetzt, dass in der Kopfzeile, genau dort, die Autorisierung

197
00:15:48,390 --> 00:15:52,820
tatsächlich enthalten ist, und Sie sehen, wie die Autorisierung enthalten ist.

198
00:15:52,820 --> 00:15:56,650
Es sagt Basic durch ein Leerzeichen

199
00:15:56,650 --> 00:16:02,980
getrennt und durch die 64-Bit-codierte Zeichenfolge getrennt, die den Benutzernamen und das Passwort enthält.

200
00:16:02,980 --> 00:16:06,080
Und dann sehen wir, dass der Server

201
00:16:06,080 --> 00:16:09,540
dies abgelehnt hat, weil die Autorisierung zu diesem Zeitpunkt falsch war.

202
00:16:09,540 --> 00:16:14,452
Später haben wir den korrekten Benutzernamen und das Passwort eingegeben.

203
00:16:14,452 --> 00:16:18,938
Also genau dort in der dritten Anfrage, die hereinkam, haben wir den richtigen Benutzernamen und

204
00:16:18,938 --> 00:16:19,597
das Passwort eingegeben.

205
00:16:19,597 --> 00:16:27,323
Deshalb sehen Sie, dass der Anforderungsheader die Autorisierung enthält,

206
00:16:27,323 --> 00:16:34,180
und diese Zeichenfolge verwendet die korrekte Kodierung des Benutzernamens und des Passworts.

207
00:16:34,180 --> 00:16:35,720
Woher weiß ich das?

208
00:16:35,720 --> 00:16:38,384
Nun, ich habe gekreuzt und weiß,

209
00:16:38,384 --> 00:16:42,337
dass, das ist die grundlegende fremd codierte Version der Zeichenfolge dort.

210
00:16:42,337 --> 00:16:47,470
Wir werden das auch von unserem Postbotenbild sehen oder was.

211
00:16:48,740 --> 00:16:53,740
Nun sehen Sie, dass die Anforderung akzeptiert wurde und

212
00:16:53,740 --> 00:16:55,740
der Wert korrekt zurückgegeben wurde.

213
00:16:57,210 --> 00:17:05,150
Und dann natürlich, später, forderte der Kunde nach einem Favicon, dem Symbol.

214
00:17:05,150 --> 00:17:11,590
Und da wir das Favicon nicht auf unserer Serverseite haben, antwortet es mit dem 404 und

215
00:17:11,590 --> 00:17:15,560
natürlich wird Ihr Lieblings-Icon nicht in der Adressleiste angezeigt.

216
00:17:15,560 --> 00:17:18,640
Also, das ist in Ordnung, aber beachten Sie insbesondere.

217
00:17:18,640 --> 00:17:21,430
Diese speziellen angeforderten kamen,

218
00:17:21,430 --> 00:17:25,030
wo der korrekte Autorisierungs-Header enthalten war.

219
00:17:25,030 --> 00:17:28,490
Und so war es damals erfolgreich.

220
00:17:28,490 --> 00:17:33,680
Lassen Sie uns mal sehen, wie wir das Gleiche mit Postmap machen können.

221
00:17:33,680 --> 00:17:38,480
Also hier habe ich mein Postkarten-Fenster geöffnet.

222
00:17:38,480 --> 00:17:42,250
Und so in meinem Postman-Fenster werde ich

223
00:17:44,160 --> 00:17:50,670
ein get to localhost eingeben: an meinen Server, und dann die Anfrage senden und

224
00:17:50,670 --> 00:17:57,260
Sie werden sofort bemerken, dass es herausfordert, zu sagen 401 nicht autorisiert.

225
00:17:57,260 --> 00:18:01,890
Dies ist also die Antwortnachricht von der Serverseite,

226
00:18:01,890 --> 00:18:06,580
so beachten Sie, was es speichert, 401 Unauthorized.

227
00:18:06,580 --> 00:18:12,550
Und es sagt, dass die Antwort ein WWW-Authenticate-Header-Feld enthalten muss.

228
00:18:12,550 --> 00:18:18,153
Und dies wird den Client herausfordern, die Autorisierungsinformationen, den

229
00:18:18,153 --> 00:18:20,083
Benutzernamen und das Passwort einzugeben.

230
00:18:20,083 --> 00:18:25,833
So sehen wir in der Vorschau, dass der Satz, den Sie nicht authentifiziert sind und

231
00:18:25,833 --> 00:18:27,940
dann der Code 401 hier.

232
00:18:27,940 --> 00:18:31,341
Betrachten Sie nun die Kopfzeilen der Antwortnachricht.

233
00:18:31,341 --> 00:18:36,781
Wenn Sie sich die Kopfzeile der Antwortnachricht ansehen, können Sie insbesondere

234
00:18:36,781 --> 00:18:41,718
diesen dort enthaltenen Header sehen, der www.authenticatebasic ist.

235
00:18:41,718 --> 00:18:46,522
Nun, wie machen wir Authentifizierung oder Autorisierung in der Post?

236
00:18:46,522 --> 00:18:51,090
Dies ist also, wo sie zu diesem direkt unter diesem Feld hier gehen würden,

237
00:18:51,090 --> 00:18:53,952
Sie werden diese Autorisierung hier sehen.

238
00:18:53,952 --> 00:18:58,050
Und wenn Sie auf die Autorisierung klicken, sagt es jetzt NO AUTH..

239
00:18:58,050 --> 00:19:01,240
Lassen Sie uns die grundlegende Authentifizierung verwenden.

240
00:19:01,240 --> 00:19:04,820
Wenn ich also grundlegende Authentifizierung sage,

241
00:19:04,820 --> 00:19:08,530
gibt es mir diese beiden Felder hier, in denen ich den Benutzernamen und das Passwort eingeben kann.

242
00:19:08,530 --> 00:19:11,160
Lassen Sie mich den richtigen Benutzernamen und das Passwort eingeben.

243
00:19:11,160 --> 00:19:19,170
Also werde ich sagen Benutzername admin, Passwort ist Passwort P-A-S-S-W-O-R-D.

244
00:19:19,170 --> 00:19:22,650
So können Sie das sehen, das ist genau das Passwort, das wir hier haben.

245
00:19:22,650 --> 00:19:26,800
Sobald Sie also den Benutzernamen und das Passwort eingeben, werden sie Update Request (Update Request) sagen.

246
00:19:26,800 --> 00:19:30,980
Wenn ich also auf Update-Anfrage klicke, würden Sie sehen, dass sofort in der Kopfzeile,

247
00:19:32,130 --> 00:19:35,340
werden Sie sehen, dass

248
00:19:35,340 --> 00:19:40,770
es dieses Feld hier gibt, das hier hinzugefügt wurde und die Autorisierung sagt.

249
00:19:40,770 --> 00:19:45,080
Und dann werden Sie sehen, was dieser zweite Teil, der Wert, den Sie nehmen können.

250
00:19:45,080 --> 00:19:49,480
Es sagt einfach und ein Leerzeichen, und dann diese bestimmte Zeichenfolge.

251
00:19:49,480 --> 00:19:55,040
Wenn Sie also diese bestimmte Zeichenfolge hier überprüfen, wird dies die genaue

252
00:19:55,040 --> 00:20:01,219
Zeichenfolge sein, die Sie in der Kopfzeile der erfolgreichen Anforderungsnachricht sehen werden.

253
00:20:01,219 --> 00:20:03,544
Beachten Sie, was diese Zeichenfolge sagt.

254
00:20:03,544 --> 00:20:09,309
Es sagt YWR etwas, und endet dann mit einem Q gleich. Wenn Sie

255
00:20:09,309 --> 00:20:14,285
zu unserem Terminal gehen, sehen Sie, dass die erfolgreiche Anfrage

256
00:20:14,285 --> 00:20:18,276
tatsächlich genau diese Zeichenfolge hier enthielt.

257
00:20:18,276 --> 00:20:24,250
Es sagt YWR und endet dann mit Q gleich dort.

258
00:20:24,250 --> 00:20:28,400
Indem Sie also die Informationen in die Autorisierung eingeben und dann auf

259
00:20:28,400 --> 00:20:34,240
die Update-Anfrage klicken, werden diese Informationen in die Autorisierungs-Header eingefügt.

260
00:20:34,240 --> 00:20:36,410
Also, jetzt ist dies eine Get-Anfrage,

261
00:20:37,410 --> 00:20:42,020
ich brauche den Inhaltstyp dort nicht, weil er keinen Körper enthält.

262
00:20:42,020 --> 00:20:46,106
Nun, da die Autorisierung eingeschlossen wurde,

263
00:20:46,106 --> 00:20:51,263
lassen Sie uns die Anfrage jetzt korrekt senden und dann werden Sie sehen, dass

264
00:20:51,263 --> 00:20:57,990
die Antwort von der Server-Site die Indexdatei enthält, wie Sie es erwarten.

265
00:20:57,990 --> 00:21:02,524
Lassen Sie mich die Autorisierung löschen.

266
00:21:02,524 --> 00:21:07,351
Dies ist der Grund, warum Postmap mir hilft, diese Dinge viel

267
00:21:07,351 --> 00:21:11,662
einfacher zu überprüfen, ich kann die Autorisierung löschen und dann die Anfrage senden.

268
00:21:11,662 --> 00:21:14,947
Und es wird immer noch diese Autorisierung enthalten,

269
00:21:14,947 --> 00:21:18,570
weil ich dies in das Autorisierungsfeld eingegeben habe.

270
00:21:18,570 --> 00:21:23,380
Also lassen Sie mich die Autorisierung von dort löschen und dann die Anfrage hier senden.

271
00:21:23,380 --> 00:21:26,000
Und dann steht, dass Sie nicht authentifiziert sind.

272
00:21:26,000 --> 00:21:30,230
Ebenso, wenn ich die Anfrage an das Geschirr schicke.

273
00:21:30,230 --> 00:21:32,000
Zuvor funktionierte das gut, aber

274
00:21:32,000 --> 00:21:37,750
jetzt sehen Sie, dass wir daran gehindert werden, auch auf den Endpunkt /Gerichte zuzugreifen.

275
00:21:37,750 --> 00:21:41,400
Und das gleiche mit allen anderen Rest APR Endpunkte auch.

276
00:21:41,400 --> 00:21:47,360
Sie haben keinen Zugriff, da die Autorisierungs-Middleware kommt, bevor

277
00:21:47,360 --> 00:21:50,600
Sie Zugriff auf einen dieser Endpunkte

278
00:21:50,600 --> 00:21:56,070
in der Liste der Middleware für Ihren Express-Server erhalten.

279
00:21:56,070 --> 00:21:59,945
Also, wenn ich jetzt die Autorisierung

280
00:22:04,774 --> 00:22:10,277
einschließe, und dann meine Anfrage aktualisieren und dann die Anfrage an den Server senden,

281
00:22:10,277 --> 00:22:12,845
dann wird der Server antworten.

282
00:22:12,845 --> 00:22:17,412
Jetzt ist offensichtlich in diesem Moment meine Datenbank leer, also

283
00:22:17,412 --> 00:22:20,752
antwortet sie dort mit einem leeren Array.

284
00:22:20,752 --> 00:22:24,109
Aber jetzt ging die Anfrage erfolgreich durch, und

285
00:22:24,109 --> 00:22:28,004
ich bin in der Lage, die Informationen von der Serversocke abzurufen.

286
00:22:28,004 --> 00:22:32,186
Dies ist also eine schnelle Demonstration der

287
00:22:32,186 --> 00:22:37,724
Grundberechtigung in unserer Express Rest APR Anwendung.

288
00:22:37,724 --> 00:22:40,730
Damit schließen wir diese Übung ab.

289
00:22:40,730 --> 00:22:42,236
Dies ist ein guter Zeitpunkt für

290
00:22:42,236 --> 00:22:46,846
Sie, einen get Kommentar mit der Nachricht der grundlegenden Authentifizierung zu tun.

291
00:22:46,846 --> 00:22:50,116
( MUSIK)