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

2
00:00:04,470 --> 00:00:10,326
Der Express REST API-Server, den wir im vorherigen

3
00:00:10,326 --> 00:00:17,750
Modul implementiert haben, ermöglicht es jedem Benutzer, eine der GET- oder POST- oder DELETE-Operationen auszuführen.

4
00:00:17,750 --> 00:00:21,360
Es gibt keine Kontrolle darüber, wer diesen Vorgang ausführen kann.

5
00:00:21,360 --> 00:00:22,350
Was bedeutet, dass,

6
00:00:22,350 --> 00:00:27,180
wenn Sie einen Server so ausführen, jeder auf Ihren Server kommen kann und

7
00:00:27,180 --> 00:00:33,420
anfangen kann, die Informationen zu manipulieren, die in Ihrer Datenbank vorhanden sind.

8
00:00:33,420 --> 00:00:36,578
Dies ist offensichtlich eine gefährliche Situation.

9
00:00:36,578 --> 00:00:40,380
Die Art und Weise, wie der Server implementiert werden sollte, ist, dass

10
00:00:40,380 --> 00:00:44,330
Sie eine Art von Einschränkung haben müssen

11
00:00:44,330 --> 00:00:48,660
, welche Arten von Benutzern erlaubt werden, welche Arten von Operationen auszuführen.

12
00:00:48,660 --> 00:00:51,090
Vielleicht würden Sie erlauben und

13
00:00:51,090 --> 00:00:54,650
einem autorisierten Benutzer nur GET-Operationen auszuführen.

14
00:00:54,650 --> 00:01:00,040
Zum Beispiel, wenn Sie möchten, dass ein Gast in der Lage sein, Informationen

15
00:01:00,040 --> 00:01:04,860
über die Gerichte in Ihrem Restaurant oder die Speisekarte Ihres Restaurants zu sehen und

16
00:01:04,860 --> 00:01:07,250
so weiter, das ist durchaus akzeptabel.

17
00:01:07,250 --> 00:01:11,699
Sie können jedoch nur einem Administrator erlauben,

18
00:01:11,699 --> 00:01:17,780
die Informationen über das Gericht zu ändern oder ein Gericht aus dem Menü zu löschen.

19
00:01:17,780 --> 00:01:23,448
Und aktualisieren Sie auch ein vorhandenes Gericht im Menü, eine Promotion,

20
00:01:23,448 --> 00:01:29,062
oder die Informationen über die Führer auf Ihrer Server-Seite.

21
00:01:29,062 --> 00:01:34,810
Jetzt könnten Sie auch eine andere Gruppe von Benutzern haben, die registrierte Benutzer sein werden

22
00:01:34,810 --> 00:01:39,980
, die berechtigt sein können, einige ihrer Gerichte als ihre Lieblingsgerichte zu speichern,

23
00:01:39,980 --> 00:01:44,290
und nur sie würden in der Lage, die Liste ihrer Lieblingsgerichte zu manipulieren.

24
00:01:44,290 --> 00:01:47,850
Das ist also eine weitere Autorisierungs- oder

25
00:01:47,850 --> 00:01:49,940
Authentifizierungsstufe, die Sie durchführen müssen.

26
00:01:49,940 --> 00:01:53,400
Sie haben also verschiedene Arten von Benutzern und

27
00:01:53,400 --> 00:01:57,820
auch, je nachdem, welche Art von Operationen sie ausführen dürfen.

28
00:01:57,820 --> 00:02:01,880
All dies bedeutet also, dass Sie irgendeine Art von Sicherheit benötigen, um

29
00:02:01,880 --> 00:02:03,840
in Ihre Serverseite eingebaut zu werden.

30
00:02:03,840 --> 00:02:07,970
Wir werden uns ansehen, wie wir Benutzer authentifizieren können, und

31
00:02:07,970 --> 00:02:13,110
dann entscheiden, welche Art von Benutzer dieser Client ist.

32
00:02:13,110 --> 00:02:15,410
Und dann

33
00:02:15,410 --> 00:02:19,360
können Sie abhängig vom Typ des Benutzers dem Benutzer erlauben, bestimmte Arten von Operationen auszuführen.

34
00:02:19,360 --> 00:02:24,630
Wir beginnen mit dem grundlegenden Verständnis dessen, was wir als

35
00:02:24,630 --> 00:02:30,860
Basic Authentication auf einer serverseitigen Seite für

36
00:02:30,860 --> 00:02:36,940
einen Client nennen, und bauen dann auf dem gesamten Rest dieses Moduls.

37
00:02:36,940 --> 00:02:42,030
Und dann am Ende dieses Moduls werden wir mit einem Mechanismus enden, der es den

38
00:02:42,030 --> 00:02:46,170
Benutzern ermöglicht, sich zu registrieren.

39
00:02:46,170 --> 00:02:50,220
Außerdem können registrierte Benutzer bestimmte Vorgänge ausführen

40
00:02:50,220 --> 00:02:53,930
, die ein nicht registrierter Benutzer nicht durchführen kann usw.

41
00:02:53,930 --> 00:02:57,320
Daher werden wir verschiedene Arten von Zugriffskontrollen für

42
00:02:57,320 --> 00:03:01,990
verschiedene Operationen auf der Serverseite basierend auf der Art des Benutzers auferlegen.

43
00:03:01,990 --> 00:03:04,930
Das setzt Sie also die Perspektive, oder

44
00:03:04,930 --> 00:03:09,830
vielmehr die Idee dessen, was Sie in diesem Modul begegnen werden.

45
00:03:09,830 --> 00:03:12,450
Beginnen wir mit der grundlegenden Authentifizierung,

46
00:03:12,450 --> 00:03:18,450
dem sehr einfachen Mechanismus, der es uns ermöglicht, Benutzer zu authentifizieren. Die

47
00:03:19,970 --> 00:03:25,173
Standardauthentifizierung in HTTP ist ein sehr einfacher Mechanismus

48
00:03:25,173 --> 00:03:28,782
, der den Benutzer nach einem Benutzernamen und

49
00:03:28,782 --> 00:03:32,720
Passwort fragt, die mit einer Anfrage gesendet werden.

50
00:03:32,720 --> 00:03:35,180
Und es gibt eine spezifische Struktur,

51
00:03:35,180 --> 00:03:39,920
wie diese Informationen vom Client zum Server gesendet werden.

52
00:03:39,920 --> 00:03:45,060
Dies ist also eine Sache, die grundlegende Zugriffsauthentifizierung, die HTTP unterstützt,

53
00:03:45,060 --> 00:03:49,860
ist eine Angelegenheit, die es einem Server ermöglicht, einen Client herauszufordern und

54
00:03:49,860 --> 00:03:53,110
den Benutzernamen und das Passwort vom Client zu übermitteln.

55
00:03:53,110 --> 00:03:57,714
So kann der Server den Client auffordern, sich zu authentifizieren, indem er diese

56
00:03:57,714 --> 00:03:59,140
Informationen eingibt.

57
00:03:59,140 --> 00:04:01,880
Der Client muss den Benutzernamen und das

58
00:04:01,880 --> 00:04:05,440
Passwort als Antwort auf die Herausforderung von der Serverseite senden.

59
00:04:05,440 --> 00:04:09,870
Daher

60
00:04:09,870 --> 00:04:13,870
sollte jede Anforderungsnachricht, die von einem Client stammt, die codierte Form des Benutzernamens und des

61
00:04:13,870 --> 00:04:19,700
Kennworts in den Anforderungsheader enthalten, der vom Client zur Serverseite geht.

62
00:04:19,700 --> 00:04:22,229
Wenn der Server die Anforderung erhält,

63
00:04:22,229 --> 00:04:27,009
extrahiert der Server diese Informationen aus dem Anforderungsheader des Clients.

64
00:04:27,009 --> 00:04:31,831
Verwenden Sie das dann für die Authentifizierung des Clients, bevor Sie

65
00:04:31,831 --> 00:04:37,390
den Zugriff auf die verschiedenen Operationen auf der Serverseite zulassen.

66
00:04:37,390 --> 00:04:40,850
Also, wie funktioniert diese Authentifizierung?

67
00:04:40,850 --> 00:04:44,450
Wenn ein Client eine Anforderung an den Server sendet und

68
00:04:44,450 --> 00:04:50,150
diese Clientanforderung die Autorisierungsformation nicht enthält, fordert der Server

69
00:04:50,150 --> 00:04:55,160
den Client heraus, er fordert den Client auf, um diese Informationen zu übermitteln.

70
00:04:55,160 --> 00:04:58,100
Der Server fordert den Client heraus, indem er

71
00:04:58,100 --> 00:05:01,900
einen Header in die Antwortnachricht einfügt.

72
00:05:01,900 --> 00:05:06,410
Der Header mit dem Typ WWW-Authenticate, und

73
00:05:06,410 --> 00:05:11,843
dann der zweite Teil, in dem er den Typ angibt, ist, wo er

74
00:05:11,843 --> 00:05:17,500
angeben wird, welche Art von Authentifizierung der Client gesendet werden muss.

75
00:05:17,500 --> 00:05:21,990
Und wir werden hier mit dem Verständnis der grundlegenden Authentifizierung beginnen.

76
00:05:21,990 --> 00:05:26,400
Beachten Sie auch, dass die Antwortnachricht einen 401-Fehlercode enthält

77
00:05:27,570 --> 00:05:31,270
, der nicht autorisiert ist, der für nicht autorisiert steht.

78
00:05:31,270 --> 00:05:35,470
Wenn die Antwort also von der Serverseite zurückkommt,

79
00:05:35,470 --> 00:05:41,300
muss der Client als Antwort auf diese Antwort, der Client seine Anfrage senden,

80
00:05:41,300 --> 00:05:49,550
einschließlich eines bestimmten Header-Feldes in der Anforderungsnachricht der Typautorisierung.

81
00:05:49,550 --> 00:05:55,250
Und dieses Autorisierungs-Header-Feld enthält einige Informationen darin.

82
00:05:55,250 --> 00:06:00,440
Für eine grundlegende Authentifizierung wäre diese Information in Form von,

83
00:06:00,440 --> 00:06:03,900
wie das erste Wort hier, wird Basic sein.

84
00:06:03,900 --> 00:06:11,410
Und dann gefolgt von einem Leerzeichen hier und gefolgt von einer Base64-codierten Zeichenfolge hier.

85
00:06:11,410 --> 00:06:15,358
Diese Base64-codierte Zeichenfolge codiert den Benutzernamen und

86
00:06:15,358 --> 00:06:21,350
das Kennwort in einem bestimmten Format und schließt diese dann in die Kopfzeile ein.

87
00:06:21,350 --> 00:06:25,479
Jetzt sagen Sie, wenn Sie eine Anforderungsnachricht wie diese senden,

88
00:06:25,479 --> 00:06:29,397
einschließlich dieser, in der Kopfzeile, dann jemand in der Mitte.

89
00:06:29,397 --> 00:06:33,538
Wenn Sie also etwas über Sicherheit wissen und

90
00:06:33,538 --> 00:06:39,927
wie man in der Mitte Angriffe gestartet werden können, dann

91
00:06:39,927 --> 00:06:44,777
kann dies offensichtlich von einem Eindringling dazwischen abgerufen werden

92
00:06:44,777 --> 00:06:49,590
und dann verwendet werden, um den echten Client zu fälschen.

93
00:06:49,590 --> 00:06:52,720
Auch hier kommen wir im Moment nicht auf diese Frage ein.

94
00:06:52,720 --> 00:06:57,470
Wenn ich im nächsten Modul über HTTPS spreche,

95
00:06:57,470 --> 00:07:00,880
werde ich zurückkommen, um dieses Problem etwas detaillierter anzugehen.

96
00:07:00,880 --> 00:07:06,060
Aber im Moment werden die Informationen im Header gesendet,

97
00:07:07,880 --> 00:07:11,930
ohne in der Header zu diesem Zeitpunkt verschlüsselt zu werden.

98
00:07:11,930 --> 00:07:15,460
Nun, ein weiterer Grund, warum ich das tue, ist, dass wir

99
00:07:15,460 --> 00:07:20,150
den Header direkt betrachten und dann diese Informationen in der Kopfzeile selbst sehen können.

100
00:07:20,150 --> 00:07:25,401
Wenn der Client diese Anforderung sendet, extrahiert der Server

101
00:07:25,401 --> 00:07:30,930
die Informationen aus diesem Autorisierungs-Header im Anforderungs-Header.

102
00:07:30,930 --> 00:07:35,078
Und dann verwenden Sie diese Informationen, um zu überprüfen, ob es sich um

103
00:07:35,078 --> 00:07:37,670
eine autorisierte Clientanfrage handelt oder nicht.

104
00:07:37,670 --> 00:07:40,412
Nun wäre Ihre nächste Frage natürlich,

105
00:07:40,412 --> 00:07:44,490
was genau enthält dieser Autorisierungs-Header?

106
00:07:44,490 --> 00:07:48,350
Der Autorisierungs-Header selbst wird wie folgt aufgebaut.

107
00:07:48,350 --> 00:07:52,180
Wenn Sie einen Benutzernamen und ein Kennwort haben, sind dies die beiden

108
00:07:52,180 --> 00:07:55,730
Informationen, die Sie verwenden, um einen Client zu authentifizieren.

109
00:07:55,730 --> 00:08:01,330
Der Benutzername und das Passwort werden also zu einer einzigen Zeichenfolge verkettet

110
00:08:01,330 --> 00:08:06,910
, indem Benutzername und Doppelpunkt und das Passwort selbst gesagt werden.

111
00:08:06,910 --> 00:08:09,860
Der Benutzername, der Doppelpunkt und

112
00:08:09,860 --> 00:08:16,210
das Passwort werden hier zu einer ganzen Zeichenfolge verkettet.

113
00:08:16,210 --> 00:08:22,994
Diese resultierende Zeichenfolge, die wir hier bekommen, ist, dass, kodiert mit Base64-Codierung.

114
00:08:22,994 --> 00:08:27,344
Wenn Sie wissen, wie die Codierung Grundlagen für die Codierung durchgeführt wird,

115
00:08:27,344 --> 00:08:32,390
konvertieren Sie diese in einen ASCII-Header wie in diesem Beispiel hier gezeigt,

116
00:08:32,390 --> 00:08:36,195
so dass dies nichts anderes als eine Zeichenfolge von ASCII-Headern ist.

117
00:08:36,195 --> 00:08:39,545
Wenn Sie nun nicht viel über grundlegende steife Codierung wissen, machen Sie sich keine Sorgen darüber,

118
00:08:39,545 --> 00:08:44,325
es hat keinen Einfluss auf Ihr Verständnis dessen, was hier vor sich geht.

119
00:08:44,325 --> 00:08:47,090
Also diese Basic64-codierten Strings, so dass

120
00:08:47,090 --> 00:08:51,950
diese spezielle Information in eine Zeichenfolge wie diese codiert und

121
00:08:51,950 --> 00:08:57,090
dann in den Anforderungsheader eingeschlossen wird, der vom Client zum Server geht.

122
00:08:57,090 --> 00:09:02,143
Der Request-Header selbst ist von der Typautorisierung,

123
00:09:02,143 --> 00:09:07,194
und dann folgt der tatsächliche Wert hier, der besagt

124
00:09:07,194 --> 00:09:13,774
, Basic, und ein Leerzeichen hier, und die Base64-codierte Zeichenfolge hier.

125
00:09:13,774 --> 00:09:20,034
Wenn dies von unserem Server empfangen wird, extrahiert der Server diese Informationen,

126
00:09:20,034 --> 00:09:25,059
und dann extrahiert er den Benutzernamen und das Passwort und

127
00:09:25,059 --> 00:09:31,620
überprüft dann, ob dies einem autorisierten Benutzer entspricht oder nicht auf der Serverseite.

128
00:09:31,620 --> 00:09:36,917
Um Ihnen zu helfen, besser zu verstehen, wie wir die Express-Anwendung tatsächlich organisieren

129
00:09:36,917 --> 00:09:42,211
und wie die Authentifizierung selbst durchgeführt wird, wie wir bereits gelernt haben,

130
00:09:42,211 --> 00:09:47,520
sind Express-Anwendungen selbst in einer Reihe von Middleware organisiert.

131
00:09:47,520 --> 00:09:51,690
Und die Art und Weise der Express-Anwendung funktioniert, ist, dass die Middleware

132
00:09:51,690 --> 00:09:55,630
auf die Anfrage und die Antwortnachricht

133
00:09:55,630 --> 00:10:00,940
in der Reihenfolge angewendet wird, in der sie in meiner Express-Anwendung deklariert wird.

134
00:10:00,940 --> 00:10:05,290
Also, wenn Sie eine express.use haben und

135
00:10:05,290 --> 00:10:09,740
dann den ersten haben, der einen statischen Server sagt, dann

136
00:10:09,740 --> 00:10:13,220
haben Sie danach eine andere Middleware, dann haben Sie eine andere Middleware.

137
00:10:13,220 --> 00:10:18,560
Die Reihenfolge, in der sie

138
00:10:18,560 --> 00:10:23,600
beispielsweise in der Datei „Express server app.js“ deklariert werden, ist die genaue Reihenfolge, in der die Middleware angewendet wird.

139
00:10:23,600 --> 00:10:29,124
Eine eingehende Anfrage von der Serverseite, wie Sie sich in Ihrer

140
00:10:29,124 --> 00:10:34,690
Express-Anwendung zurückrufen, wird die eingehende Anfrage als Anforderungsobjekt behandelt.

141
00:10:34,690 --> 00:10:39,050
Das Antwortobjekt ist das, was

142
00:10:39,050 --> 00:10:43,310
der Express-Server konstruiert, und dann können Sie mit der nächsten Middleware

143
00:10:43,310 --> 00:10:45,910
fortfahren, die Sie anwenden werden, usw.

144
00:10:45,910 --> 00:10:52,400
Also, eine eingehende Anfrage wie diese, wenn sie hereinkommt, wird die erste Middleware angewendet.

145
00:10:52,400 --> 00:10:56,164
Und sobald diese Middleware sowohl die Anfrage als auch

146
00:10:56,164 --> 00:11:00,680
die Antwort transformiert hat, geht sie zur nächsten Middleware über, die dann auf sie angewendet wird.

147
00:11:00,680 --> 00:11:03,940
So haben wir zum Beispiel gesehen, dass wir Morgan zuerst angewendet haben,

148
00:11:03,940 --> 00:11:06,930
dann haben wir Body Parser auf die Middleware angewendet.

149
00:11:06,930 --> 00:11:12,930
Sie müssen also bereits die Anforderung und die Antwortobjekte transformiert haben.

150
00:11:12,930 --> 00:11:17,440
Und danach können wir dort eine Authentifizierungs-Middleware einbinden.

151
00:11:17,440 --> 00:11:22,260
Die Authentifizierungs-Middleware wird die Anforderung authentifizieren.

152
00:11:22,260 --> 00:11:26,950
Wenn Sie also die Standardauthentifizierung verwenden,

153
00:11:26,950 --> 00:11:31,970
muss Ihre Anfrage im Header den Autorisierungsheader enthalten, der dort vorhanden ist.

154
00:11:31,970 --> 00:11:36,260
Daher wird der Autorisierungs-Header von der Authentifizierungs-Middleware extrahiert

155
00:11:36,260 --> 00:11:40,180
und dann überprüft, ob der Benutzer autorisiert ist.

156
00:11:40,180 --> 00:11:46,099
Und wenn die Authentifizierungs-Middleware erkennt, dass Sie ein autorisierter Benutzer sind,

157
00:11:46,099 --> 00:11:50,515
können Sie mit dem nächsten Satz

158
00:11:50,515 --> 00:11:54,427
Middleware fortfahren, der dem Authentifizierungsschritt folgt.

159
00:11:54,427 --> 00:11:58,510
Und Ihre Unterlagen werden von der nachfolgenden Middleware verarbeitet.

160
00:11:58,510 --> 00:11:59,519
Andererseits,

161
00:11:59,519 --> 00:12:04,422
wenn Ihre Authentication Middleware entscheidet, dass Sie kein autorisierter Benutzer sind,

162
00:12:04,422 --> 00:12:09,197
dann wird die Authentication Middleware Sie auf einen anderen Weg führen.

163
00:12:09,197 --> 00:12:13,975
Und dann generieren Sie einen Fehler, und senden Sie dann

164
00:12:13,975 --> 00:12:19,368
eine entsprechende Fehlerantwort an diese Client-Seite zurück und

165
00:12:19,368 --> 00:12:24,010
wird an den Fehlerbehandler umgeleitet.

166
00:12:24,010 --> 00:12:28,450
Diese Umleitung zum Fehlerhandler wird also durch Aufrufen von Next

167
00:12:28,450 --> 00:12:32,490
mit dem Fehler als Parameter zu diesem Next hier durchgeführt.

168
00:12:32,490 --> 00:12:38,240
Also der Nächste ist genau dieser Nächste, den wir in der Anforderungsressource sehen Weiter hier.

169
00:12:38,240 --> 00:12:42,760
Und das führt Sie den ganzen Weg bis zum Fehlerhandler, der Fehler behandelt

170
00:12:42,760 --> 00:12:48,170
und dann die Fehlermeldung zurück an die Client-Seite sendet,

171
00:12:48,170 --> 00:12:51,820
was auf den Fehler der Authentifizierung hinweist.

172
00:12:51,820 --> 00:12:56,720
So

173
00:12:56,720 --> 00:13:03,435
funktioniert Ihre typische grundlegende Autorisierung oder Standardauthentifizierung in Ihrer serverseitigen Anwendung.

174
00:13:03,435 --> 00:13:08,305
Nachdem wir dies verstanden haben, gehen wir zu der Übung über, wo

175
00:13:08,305 --> 00:13:13,176
wir die grundlegende Authentifizierung in unserer Anwendung implementieren und

176
00:13:13,176 --> 00:13:15,717
sehen, wie sie Benutzer authentifiziert.

177
00:13:15,717 --> 00:13:17,952
( MUSIK)