1
00:00:00,000 --> 00:00:05,340
Nachdem wir nun die

2
00:00:05,340 --> 00:00:11,610
Implementierung des REST-API-Servers mit Express und MongoDB in diesem Kurs abgeschlossen haben,

3
00:00:11,610 --> 00:00:14,990
ist der nächste sofortige Gedanke, der in Ihrem Kopf auftreten könnte,

4
00:00:14,990 --> 00:00:18,555
da wir bereits die Client-Anwendungen entwickelt haben,

5
00:00:18,555 --> 00:00:21,460
egal ob es sich um die Angular-Anwendung, die Ionic Anwendung

6
00:00:21,460 --> 00:00:25,380
oder die Native Script-Anwendung in den vorherigen Kursen,

7
00:00:25,380 --> 00:00:29,820
wie integrieren wir die beiden zusammen, so dass unsere Client-Anwendung in der Lage ist,

8
00:00:29,820 --> 00:00:35,780
mit dem vollwertigen REST-API-Server zu interagieren, den wir in diesem Kurs entwickelt haben? Das

9
00:00:35,780 --> 00:00:39,605
werden wir also in dieser Lektion,

10
00:00:39,605 --> 00:00:44,715
in diesem Vortrag und den beiden Übungen, die dieser Vorlesung folgen, untersuchen.

11
00:00:44,715 --> 00:00:46,655
Am Ende dieser Lektion

12
00:00:46,655 --> 00:00:49,295
haben Sie also einen Angular-Client, den wir

13
00:00:49,295 --> 00:00:52,220
mit dem Server kommunizieren können, den Sie gerade in

14
00:00:52,220 --> 00:00:55,265
diesem Kurs entwickelt haben, und in der Lage sein,

15
00:00:55,265 --> 00:01:01,410
die vollwertige Client-Seitenansicht unserer gesamten Anwendung zu unterstützen.

16
00:01:01,410 --> 00:01:03,860
Auf diese Weise werden wir sehen, dass wir

17
00:01:03,860 --> 00:01:11,150
die komplette End-to-End-Anwendung von der Client-Seite bis zur Serverseite entwickelt haben.

18
00:01:11,150 --> 00:01:13,895
Ein ähnlicher Ansatz kann auch mit

19
00:01:13,895 --> 00:01:17,290
Ihrem Ionic Client oder mit Ihrem Native Skript-Client verwendet werden,

20
00:01:17,290 --> 00:01:20,430
da sowohl Ionic als auch Native Skript

21
00:01:20,430 --> 00:01:24,420
mit der Angular-Engine hinter den Kulissen entwickelt wurden. Die

22
00:01:24,420 --> 00:01:31,100
Durchführung ähnlicher Schritte sollte also in der Lage sein, Ihren Ionic Client und auch

23
00:01:31,100 --> 00:01:35,240
Ihren Native Skript-Client mit dem Express

24
00:01:35,240 --> 00:01:40,295
plus MongoDB Rest API-Server zu kommunizieren, den wir in diesem Kurs entwickelt haben.

25
00:01:40,295 --> 00:01:44,810
Um den Client und den Server zu integrieren,

26
00:01:44,810 --> 00:01:50,020
ist unser Server bereits implementiert, um die vollwertige REST-API zu unterstützen.

27
00:01:50,020 --> 00:01:51,695
Von unserer Client-Seite,

28
00:01:51,695 --> 00:01:53,240
unabhängig davon, ob es sich um den Winkel-Client,

29
00:01:53,240 --> 00:01:55,750
den ionischen Client oder den nativen Skriptclient handelt,

30
00:01:55,750 --> 00:02:00,740
interagieren sie alle mit dem Server über die REST-API-Endpunkte.

31
00:02:00,740 --> 00:02:06,135
Wenn der Client die Anforderung an den Server am REST-API-Endpunkt sendet,

32
00:02:06,135 --> 00:02:10,729
antwortet der Server mit den entsprechenden JSON-Daten zurück an den Client,

33
00:02:10,729 --> 00:02:16,720
und der Client kann dann die JSON-Daten verwenden, um die Ansichten für den Benutzer zu rendern.

34
00:02:16,720 --> 00:02:22,970
Angesichts dieses Verständnisses der Kommunikation zwischen dem Client und dem Server

35
00:02:22,970 --> 00:02:25,780
sollte die Integration ziemlich einfach sein.

36
00:02:25,780 --> 00:02:26,960
Aber jetzt,

37
00:02:26,960 --> 00:02:30,820
als wir unseren Angular oder den Ionic oder den NativeScript-Client entwickelten,

38
00:02:30,820 --> 00:02:34,990
haben wir den vollwertigen Benutzerauthentifizierungsteil nicht gemacht,

39
00:02:34,990 --> 00:02:38,225
da wir diesen nicht in unserem JSON-Server hatten.

40
00:02:38,225 --> 00:02:43,250
Jetzt, da wir die Benutzerauthentifizierung in unsere Serverseite integriert haben,

41
00:02:43,250 --> 00:02:47,810
müssen wir unsere Client-Anwendungen nachrüsten,

42
00:02:47,810 --> 00:02:52,970
damit sie die Benutzerauthentifizierung auf der Serverseite durchführen können,

43
00:02:52,970 --> 00:02:56,660
indem wir die Anmeldeinformationen auf dem Server veröffentlichen und dann

44
00:02:56,660 --> 00:03:01,190
das Authentifizierungstoken von der Serverseite erhalten,

45
00:03:01,190 --> 00:03:04,400
und danach die Kommunikation mit dem Server einschließlich des

46
00:03:04,400 --> 00:03:08,175
Authentifizierungstoken in der Kopfzeile der Anforderungsnachrichten.

47
00:03:08,175 --> 00:03:10,130
All dies bedeutet also, dass wir

48
00:03:10,130 --> 00:03:12,860
kleinere Anpassungen sowohl am Client als auch am Server vornehmen müssen,

49
00:03:12,860 --> 00:03:15,860
damit die beiden miteinander kommunizieren können.

50
00:03:15,860 --> 00:03:21,020
Ein Aspekt, den ich in der Übung zuvor nicht behandelt habe,

51
00:03:21,020 --> 00:03:26,445
ist, wie der Server die Abfrageparameter handhabt, die von der Clientseite stammen.

52
00:03:26,445 --> 00:03:27,970
Also, wie wir erkannt haben,

53
00:03:27,970 --> 00:03:31,925
wenn die Client-Seite eine Anfrage für ein

54
00:03:31,925 --> 00:03:37,360
vorgestelltes Gericht oder einen vorgestellten Führer oder eine Feature-Promotion sendet,

55
00:03:37,360 --> 00:03:41,665
sahen wir, dass die URL Geschirr enthält,

56
00:03:41,665 --> 00:03:45,095
Fragezeichen-Funktion ist gleich wahr in

57
00:03:45,095 --> 00:03:48,840
der Anforderungs-URL, die von der Client-Seite kommt.

58
00:03:48,840 --> 00:03:51,670
Jetzt

59
00:03:51,670 --> 00:03:54,040
haben wir in den Daten auf der Serverseite bereits gesehen, dass das Gericht, die

60
00:03:54,040 --> 00:03:56,090
Förderung oder der Führer, das

61
00:03:56,090 --> 00:03:59,835
Feature-Flag bereits in den JSON-Daten enthält.

62
00:03:59,835 --> 00:04:02,975
Wenn diese Anforderung auf die Serverseite kommt,

63
00:04:02,975 --> 00:04:10,285
sollte der Server in der Lage sein, diesen Abfrageparameter aus der eingehenden Anfrage zu extrahieren,

64
00:04:10,285 --> 00:04:16,865
und dann die Abfrage der

65
00:04:16,865 --> 00:04:24,485
MongoDB entsprechend durchzuführen und dann nur die Ergebnisse zu erhalten, bei denen dieses Feature-Flag auf true gesetzt ist.

66
00:04:24,485 --> 00:04:26,365
Also, um das zu tun, wie wir gesehen haben,

67
00:04:26,365 --> 00:04:36,380
ist die URL, die verwendet wird, um die Anfrage an den Server zu senden, /dish? feature=true.

68
00:04:36,380 --> 00:04:42,365
Also, so werden wir die Abfrageparameter auf unserer Serverseite liefern.

69
00:04:42,365 --> 00:04:47,510
Nun, zusätzlich, wenn diese Informationen auf der Serverseite empfangen werden,

70
00:04:47,510 --> 00:04:51,890
haben wir gesehen, dass früher, als wir die get-Anfrage auf der Serverseite gemacht haben,

71
00:04:51,890 --> 00:04:56,975
wir einfach gesagt, Gerichte finden und dann würden wir alle Gerichte finden und dann zurückgeben,

72
00:04:56,975 --> 00:05:03,675
wenn die get-Anfrage an die DishRouterRoute/ gesendet wird.

73
00:05:03,675 --> 00:05:09,470
Die gleiche Logik gilt sowohl für den Promo-Router als auch für den Leader Router.

74
00:05:09,470 --> 00:05:14,805
Wenn Sie nun einen Abfrageparameter wie diesen in die URL einfügen,

75
00:05:14,805 --> 00:05:19,270
wie wird unsere Serverseite in der Lage sein, diesen Abfrageparameter zu extrahieren?

76
00:05:19,270 --> 00:05:22,730
Wenn die eingehende Anforderung

77
00:05:22,730 --> 00:05:27,055
diesen Abfrageparameter an die eingehende URL angehängt hat,

78
00:05:27,055 --> 00:05:31,835
verarbeitet der Express-Server diesen automatisch und wandelt ihn in

79
00:05:31,835 --> 00:05:38,910
ein JSON-Objekt um, das in eine Anforderungsnachricht geladen wird, die auf der Serverseite eingeht.

80
00:05:38,910 --> 00:05:45,185
Nun ist dies serverseitig in Form von req.query verfügbar.

81
00:05:45,185 --> 00:05:49,665
Also, unabhängig von Abfrageparametern, die Sie in die URL einfügen,

82
00:05:49,665 --> 00:05:56,860
werden in entsprechende JSON-Objekte mit den Informationen umgewandelt, die hier festgelegt sind,

83
00:05:56,860 --> 00:06:01,350
und dann auf das Anforderungsobjekt auf der Serverseite geladen.

84
00:06:01,350 --> 00:06:04,670
Also, durch die Verwendung von req.query auf der Serverseite,

85
00:06:04,670 --> 00:06:08,105
werden wir in der Lage sein, diese Abfrageparameter zu erhalten.

86
00:06:08,105 --> 00:06:11,840
Also, wenn Sie eine get-Anfrage auf der Serverseite ausführen,

87
00:06:11,840 --> 00:06:18,635
sagen Sie dishes.find und dann fügen Sie die req.query in die Suche dort ein.

88
00:06:18,635 --> 00:06:25,040
Wenn also die MongoDB abgefragt wird,

89
00:06:25,040 --> 00:06:31,160
werden nur die Datensätze oder nur die Dokumente, für die das Featured auf true gesetzt ist,

90
00:06:31,160 --> 00:06:38,270
aus der MongoDB extrahiert und uns innerhalb dieser get-Methode hier zurückgegeben

91
00:06:38,270 --> 00:06:41,625
und können dann an die Client-Seite zurückgegeben werden.

92
00:06:41,625 --> 00:06:49,745
Dies ist also so einfach wie bei der Verarbeitung der Abfrageparameter auf unserer Serverseite.

93
00:06:49,745 --> 00:06:55,135
Also, dieses Update werden wir sowohl mit dem Dish Router,

94
00:06:55,135 --> 00:07:01,225
dem Promo-Router als auch dem Leader Router auf unserer Serverseite tun.

95
00:07:01,225 --> 00:07:04,880
Der nächste Teil ist natürlich die Benutzerauthentifizierung.

96
00:07:04,880 --> 00:07:07,530
Wie wir auf der Serverseite festgestellt haben,

97
00:07:07,530 --> 00:07:11,095
haben wir bereits diese REST-API-Endpunkte,

98
00:07:11,095 --> 00:07:13,780
die für die Benutzerauthentifizierung nützlich sind.

99
00:07:13,780 --> 00:07:18,855
Insbesondere, wenn Sie einen Beitrag zu /users/login

100
00:07:18,855 --> 00:07:22,040
mit dem Benutzernamen und Passwort machen,

101
00:07:22,040 --> 00:07:26,140
dann können Sie den Benutzer auf der Serverseite authentifizieren.

102
00:07:26,140 --> 00:07:30,535
Wenn der Benutzer nun auf der Serverseite erfolgreich authentifiziert wurde,

103
00:07:30,535 --> 00:07:35,059
enthält die Antwortnachricht, die von der Serverseite kommt,

104
00:07:35,059 --> 00:07:43,345
das JSON-Web-Token in den Antworttext der eingehenden Antwortnachricht von der Serverseite.

105
00:07:43,345 --> 00:07:44,810
Also, auf der Client-Seite

106
00:07:44,810 --> 00:07:49,210
sollten wir in der Lage sein, dieses Token zu extrahieren und dann dieses Token später zu verwenden.

107
00:07:49,210 --> 00:07:52,700
Wenn also der Client die Antwortnachricht von

108
00:07:52,700 --> 00:07:57,140
der Serverseite empfängt und der Benutzer erfolgreich auf der Serverseite authentifiziert wurde,

109
00:07:57,140 --> 00:07:59,690
enthält die Antwortnachricht das JSON-Web-Token,

110
00:07:59,690 --> 00:08:02,290
das extrahiert werden muss, und danach

111
00:08:02,290 --> 00:08:05,240
sollte der Client dieses JSON-Web-Token in

112
00:08:05,240 --> 00:08:10,620
die Autorisierungs-Header für jede ausgehende Anforderung von der Client-Seite.

113
00:08:10,620 --> 00:08:13,585
Also, wie gehen wir mit diesem ganzen Satz von Operationen um?

114
00:08:13,585 --> 00:08:15,800
Nun, hier werden wir

115
00:08:15,800 --> 00:08:20,255
einen anderen Dienst implementieren, der auf unserer Client-Seite verwendet wird,

116
00:08:20,255 --> 00:08:21,720
in unserem Angular-Client,

117
00:08:21,720 --> 00:08:23,810
genannt Authentifizierungsdienst,

118
00:08:23,810 --> 00:08:30,185
und dort werden wir die gesamte Login- und Abmeldeoperationen behandeln.

119
00:08:30,185 --> 00:08:33,850
Nun ist der Abmeldevorgang ziemlich einfach, aber

120
00:08:33,850 --> 00:08:37,840
wenn wir das JSON-Web-Token zerstören, das wir auf der Clientseite

121
00:08:37,840 --> 00:08:41,160
haben, kann der Client nicht mehr auf den Server zugreifen.

122
00:08:41,160 --> 00:08:43,850
Es ist also so einfach wie das Löschen

123
00:08:43,850 --> 00:08:48,095
des JSON-Web-Token auf der Clientseite zum Abmelden dieses Clients.

124
00:08:48,095 --> 00:08:50,460
Angesichts dieses Verständnisses

125
00:08:50,460 --> 00:08:54,110
sehen wir uns also die Schritte an, die bei

126
00:08:54,110 --> 00:08:59,760
der Benutzerauthentifizierung und der Handhabung der Benutzerauthentifizierung auf der Clientseite beteiligt sind.

127
00:08:59,760 --> 00:09:03,320
Um die Benutzerauthentifizierung auf der Clientseite zu bearbeiten,

128
00:09:03,320 --> 00:09:08,945
sendet der Client eine Post-Anfrage an den /users/login Endpunkt,

129
00:09:08,945 --> 00:09:14,110
und der Text der Post-Anfrage enthält den Benutzernamen und das Passwort.

130
00:09:14,110 --> 00:09:16,660
Wir verwenden in diesem Fall die Login-Authentifizierung.

131
00:09:16,660 --> 00:09:18,650
Nun, für die Facebook-Authentifizierung wieder,

132
00:09:18,650 --> 00:09:22,355
das ist ein anderes Setup, das ich jetzt nicht diskutieren werde.

133
00:09:22,355 --> 00:09:26,465
Der Anforderungstext, wie Sie für die lokale Authentifizierung

134
00:09:26,465 --> 00:09:28,730
sehen, enthält jedoch den Benutzernamen und das Kennwort.

135
00:09:28,730 --> 00:09:33,170
Wenn der Benutzer also erfolgreich auf der Serverseite authentifiziert wurde,

136
00:09:33,170 --> 00:09:36,410
antwortet der Server dann an den

137
00:09:36,410 --> 00:09:41,425
Client zurück, indem er das JSON-Web-Token in die Antwortnachricht einschließt.

138
00:09:41,425 --> 00:09:46,070
Wenn der Client die Antwortnachricht von der Serverseite empfängt,

139
00:09:46,070 --> 00:09:49,790
muss der Client dieses JSON-Web-Token erfassen

140
00:09:49,790 --> 00:09:55,025
und dann das JSON-Web-Token im lokalen Speicher auf der Clientseite speichern.

141
00:09:55,025 --> 00:10:01,250
Danach sollte der Client dieses Token in jede ausgehende Anforderung aufnehmen.

142
00:10:01,250 --> 00:10:04,455
Also, wie wird das auf der Client-Seite erreicht?

143
00:10:04,455 --> 00:10:06,155
In erster Linie

144
00:10:06,155 --> 00:10:11,980
müssen Sie natürlich das eingehende JSON-Web-Token im lokalen Speicher speichern,

145
00:10:11,980 --> 00:10:16,790
und das geschieht im Authentifizierungsdienst, den wir auf der Clientseite implementieren.

146
00:10:16,790 --> 00:10:19,975
Jetzt

147
00:10:19,975 --> 00:10:22,850
wird der Client für jede ausgehende Anforderung dieses Token in den Header aufnehmen,

148
00:10:22,850 --> 00:10:27,100
den Autorisierungs-Header der ausgehenden Anforderung.

149
00:10:27,100 --> 00:10:28,555
Nun, wie wird das erreicht?

150
00:10:28,555 --> 00:10:33,935
Also, hier werden wir die Hilfe eines HTTP-Abfangs nehmen

151
00:10:33,935 --> 00:10:37,265
, den der HttpClient in Angular unterstützt.

152
00:10:37,265 --> 00:10:39,675
Mit dem

153
00:10:39,675 --> 00:10:42,305
HTTP-Interceptor können wir also

154
00:10:42,305 --> 00:10:45,875
jede ausgehende Anforderungsnachricht abfangen oder sogar

155
00:10:45,875 --> 00:10:50,010
jede eingehende Antwortnachricht abfangen, wenn Sie dies wünschen.

156
00:10:50,010 --> 00:10:52,175
Aber in der Angular-Anwendung

157
00:10:52,175 --> 00:10:56,215
werden wir den Anforderungsinterceptor implementieren

158
00:10:56,215 --> 00:11:02,460
, den ich später in der Übung veranschaulichen werde.

159
00:11:02,460 --> 00:11:04,375
Wenn im HTTP-Anforderungsinterceptor die Anforderungsnachricht abgefangen wird, wird

160
00:11:04,375 --> 00:11:09,915
jede ausgehende Anforderungsnachricht abgefangen und dann wird das JSON-Web-Token

161
00:11:09,915 --> 00:11:15,650
in den Autorisierungs-Header der Anforderungsnachricht eingefügt.

162
00:11:15,650 --> 00:11:20,290
Danach würde die Anforderungsnachricht an die Serverseite weitergegeben werden.

163
00:11:20,290 --> 00:11:26,825
Daher trägt jede ausgehende Anforderung, nachdem der Benutzer auf der Serverseite authentifiziert wurde,

164
00:11:26,825 --> 00:11:30,620
jede ausgehende Anfrage von der Clientseite

165
00:11:30,620 --> 00:11:35,590
das JSON-Web-Token im Autorisierungsheader der ausgehenden Anforderung.

166
00:11:35,590 --> 00:11:38,600
Sobald sich der Client abmeldet,

167
00:11:38,600 --> 00:11:42,595
wird das JSON-Web-Token auf der Clientseite zerstört.

168
00:11:42,595 --> 00:11:47,215
Danach enthalten ausgehende Anforderungen das JSON-Web-Token nicht mehr,

169
00:11:47,215 --> 00:11:50,160
da das JSON-Web-Token auf der Clientseite nicht existiert.

170
00:11:50,160 --> 00:11:53,240
Dadurch verliert der Benutzer die Authentifizierung.

171
00:11:53,240 --> 00:12:00,030
So werden wir den Anmelde- und Abmeldeprozess auf der Clientseite behandeln,

172
00:12:00,030 --> 00:12:02,290
indem wir mit dem Server kommunizieren

173
00:12:02,290 --> 00:12:04,225
und dann das JSON-Web-Token erhalten

174
00:12:04,225 --> 00:12:08,845
und dann das JSON-Web-Token in jede ausgehende Anforderung einschließen.

175
00:12:08,845 --> 00:12:14,250
Nun, mit diesem Verständnis, wie der Client und der Server interagieren,

176
00:12:14,250 --> 00:12:18,205
gehen wir jetzt mit den nächsten zwei Übungen über.

177
00:12:18,205 --> 00:12:22,540
Zunächst werden wir die Serverseite mit ein paar Ergänzungen aktualisieren,

178
00:12:22,540 --> 00:12:28,220
so dass es gut in unsere Client-Website integriert werden kann.

179
00:12:28,220 --> 00:12:32,750
Danach werden wir die Client-Seite aktualisieren oder vielmehr werde ich Ihnen

180
00:12:32,750 --> 00:12:36,215
eine vollwertige Client-Anwendung geben, die ich

181
00:12:36,215 --> 00:12:40,795
aus dem früheren Angular-Kurs genommen habe, und dann werde ich sie aktualisiert,

182
00:12:40,795 --> 00:12:45,875
was uns auch die Möglichkeit bietet,

183
00:12:45,875 --> 00:12:51,595
HTTP-Interceptoren sowohl für die ausgehenden Anfragen als auch für die eingehende Antwortnachrichten.

184
00:12:51,595 --> 00:12:56,090
Also, wir werden beide in den nächsten zwei Übungen behandeln,

185
00:12:56,090 --> 00:12:58,370
und am Ende werden Sie verstehen, wie Sie

186
00:12:58,370 --> 00:13:02,530
Ihren Client und die Serverseite integrieren können.