1
00:00:00,000 --> 00:00:04,746
[MUSIK]

2
00:00:04,746 --> 00:00:08,050
Lasst uns jetzt in einer CORS-Sprache reden.

3
00:00:08,050 --> 00:00:11,500
Was genau ist das gemeinsame Teilen von Ergebnissen, und

4
00:00:11,500 --> 00:00:15,325
warum ist es relevant, wenn wir Webanwendungen und

5
00:00:15,325 --> 00:00:21,010
hypermobile Anwendungen betrachten, wie wir es in dieser Spezialisierung getan haben?

6
00:00:21,010 --> 00:00:25,260
Wie Sie verstehen, ziehen die meisten Webseiten jetzt Daten von

7
00:00:25,260 --> 00:00:29,790
vielen verschiedenen Websites ein, um eine Webseite zu erstellen.

8
00:00:29,790 --> 00:00:38,470
Nun, um eine strenge Politik des Zugriffs auf Ressourcen von verschiedenen Websites durchzusetzen,

9
00:00:38,470 --> 00:00:44,220
wurde die gleiche Ursprungspolitik von vielen Browsern auferlegt.

10
00:00:44,220 --> 00:00:49,410
Wir werden auf den nächsten Folien ein wenig ausführlicher darüber sprechen, aber

11
00:00:49,410 --> 00:00:55,950
im Zusammenhang mit den Frameworks, die wir in dieser speziellen

12
00:00:55,950 --> 00:01:00,640
Spezialisierung diskutiert haben, wie Angular, Ionic und NativeScript,

13
00:01:00,640 --> 00:01:05,650
werden viele von ihnen Skripte, JavaScript-Code,

14
00:01:05,650 --> 00:01:11,220
die möglicherweise Zugriff auf Ressourcen von verschiedenen Websites.

15
00:01:11,220 --> 00:01:16,790
Und das ist, wo das CORS-Problem sehr leicht auftaucht.

16
00:01:16,790 --> 00:01:22,290
Lassen Sie uns sehen, wie wir dieses Problem in diesem Vortrag und

17
00:01:22,290 --> 00:01:24,050
der folgenden Übung ausführlicher behandeln werden.

18
00:01:25,940 --> 00:01:31,446
Ich habe kurz auf die Politik der gleichen Herkunft angedeutet, die ich mit diesem Vortrag begonnen habe.

19
00:01:31,446 --> 00:01:36,510
Nun ist die gleiche Ursprungsrichtlinie ein Web-App-Sicherheitsmodell,

20
00:01:36,510 --> 00:01:40,170
das einschränkt, wie ein Dokument oder ein Skript, das

21
00:01:40,170 --> 00:01:45,380
von einem Ursprung geladen wird, mit Ressourcen aus einem anderen Ursprung interagiert.

22
00:01:45,380 --> 00:01:50,270
Dies dient dazu, potenziell schädliche Dokumente zu isolieren.

23
00:01:50,270 --> 00:01:54,940
Nun offensichtlich, wenn Sie eine Webseite haben, die Skript,

24
00:01:54,940 --> 00:02:00,900
JavaScript-Code enthält, die auf Ressourcen von einem anderen Ort zugreifen könnte,

25
00:02:00,900 --> 00:02:05,185
könnte potenziell bösartiger Code in Ihre Webseite injiziert werden und

26
00:02:05,185 --> 00:02:12,800
durch den Zugriff auf einen anderen Ursprung als von wo aus Ihre Webseite abgerufen wird.

27
00:02:12,800 --> 00:02:17,220
Nun, das ist der Grund, warum viele Browser diese gleiche Ursprungsrichtlinie auferlegen.

28
00:02:17,220 --> 00:02:22,230
Nun, wenn wir über die gleiche Herkunft sprechen, wie geben wir einen Ursprung an?

29
00:02:22,230 --> 00:02:28,540
In diesem Zusammenhang wird nun ein Ursprung für jede Ressource durch drei Tupel definiert.

30
00:02:28,540 --> 00:02:32,980
Zuerst das Protokoll, das für den Zugriff auf die Ressource verwendet wird.

31
00:02:32,980 --> 00:02:39,410
Zweitens der Hostname der Ressource oder die Domäne dieser Ressource.

32
00:02:39,410 --> 00:02:43,480
Und drittens die Portnummer, unter der auf diese Ressource zugegriffen wird.

33
00:02:43,480 --> 00:02:48,700
So identifizieren wir den Ursprung jeder Ressource.

34
00:02:48,700 --> 00:02:53,626
Ressource könnte in diesem Fall eine HTML-Seite, ein Bild,

35
00:02:53,626 --> 00:03:00,720
JSON-Daten, die von einem REST-API-Endpunkt abgerufen werden, und vieles mehr sein.

36
00:03:00,720 --> 00:03:05,410
Um die gleiche Ursprungspolitik weiter zu erläutern, schauen wir uns ein Beispiel an.

37
00:03:05,410 --> 00:03:12,315
Angenommen, wir haben eine Webseite, die von dieser Website geladen wird, die hier aufgelistet ist

38
00:03:12,315 --> 00:03:17,330
, www.abc.com, und in einem Ordner xyz, und

39
00:03:17,330 --> 00:03:21,210
die page.html wird hier geladen.

40
00:03:21,210 --> 00:03:26,890
Diese Seite kann Links oder sogar JavaScript-Code enthalten, der

41
00:03:26,890 --> 00:03:33,200
XMLHttpRequest für andere Ressourcen auf der Webseite ausgibt.

42
00:03:33,200 --> 00:03:38,310
Nun, in diesem Fall, wenn wir versuchen, auf eine andere URL zuzugreifen, zum

43
00:03:38,310 --> 00:03:42,690
Beispiel, die erste hier aufgelistet, die offensichtlich Sie sehen, stammt

44
00:03:42,690 --> 00:03:47,860
von der gleichen Website, aber von einem anderen Ordner.

45
00:03:47,860 --> 00:03:51,820
Dies ist akzeptabel, da der Ursprung, in diesem Fall

46
00:03:51,820 --> 00:03:55,420
das verwendete Protokoll und die Portnummer, gleich bleibt.

47
00:03:55,420 --> 00:04:00,660
Dies ist also akzeptabel, um auf diese Ressource zuzugreifen.

48
00:04:00,660 --> 00:04:05,470
Ähnlich im zweiten Fall haben wir unter

49
00:04:07,040 --> 00:04:10,570
mehreren Ebenen von Unterordnern eine Ressource, auf die zugegriffen wird.

50
00:04:10,570 --> 00:04:15,850
Aber wieder, da ihr Ursprung gleich bleibt, was akzeptabel ist.

51
00:04:15,850 --> 00:04:18,260
Aber schauen wir uns das dritte Beispiel hier an.

52
00:04:18,260 --> 00:04:23,930
In diesem Beispiel sehen wir, dass wir versuchen, hier mit

53
00:04:23,930 --> 00:04:31,230
dem https-Protokoll auf eine Ressource zuzugreifen, was offensichtlich gegen den gleichen Ursprung Prinzipal verstößt,

54
00:04:31,230 --> 00:04:35,580
da wir ein anderes Protokoll verwenden, um an dieser Stelle auf diese Ressource zuzugreifen.

55
00:04:35,580 --> 00:04:39,030
Das würde also in diesem Fall als Fehler angesehen werden.

56
00:04:39,030 --> 00:04:44,840
Der vierte Fall ist, wo wir auf eine Ressource mit einer anderen Portnummer zugreifen.

57
00:04:44,840 --> 00:04:50,300
Und der fünfte Fall ist, wo wir auf eine Ressource auf einem anderen Host zugreifen.

58
00:04:50,300 --> 00:04:54,830
Nun würden alle diese drei als ungültig markiert oder

59
00:04:54,830 --> 00:04:58,110
können nicht unter dieser gleichen Ursprungsrichtlinie zugegriffen werden.

60
00:04:58,110 --> 00:05:02,710
Wenn Sie also die gleiche Ursprungsrichtlinie für den Zugriff von

61
00:05:02,710 --> 00:05:10,970
Ihrem XMLHttpRequest auferlegen, wären die letzten drei in diesem Fall nicht zulässig.

62
00:05:10,970 --> 00:05:16,270
Aber natürlich gibt es viele Situationen, in denen dieser Website-Designer

63
00:05:16,270 --> 00:05:22,510
tatsächlich Ressourcen auf verschiedenen Websites hosten kann, vielleicht auf verschiedenen Domänen,

64
00:05:22,510 --> 00:05:27,128
und immer noch in der Lage sein, die Daten einzuziehen, um die Webseite

65
00:05:27,128 --> 00:05:32,120
zu konstruieren oder die Webanwendung auszuführen oder um die hybride mobile Anwendung auszuführen .

66
00:05:32,120 --> 00:05:38,914
Um diesen Situationen gerecht zu werden,

67
00:05:38,914 --> 00:05:44,798
ist die Cross-Origin Request Handling eine Methode, die es uns ermöglicht, auf diese Ressourcen zuzugreifen.

68
00:05:44,798 --> 00:05:50,410
Daher betrachten wir eine Anfrage als

69
00:05:50,410 --> 00:05:56,290
Cross-Origin-Anfrage, wenn Sie versuchen, auf eine Ressource von einer anderen Domäne

70
00:05:56,290 --> 00:06:01,240
oder von einer anderen Portnummer oder mit einem anderen Protokoll zuzugreifen.

71
00:06:01,240 --> 00:06:06,920
Wie können wir Situationen berücksichtigen, in denen es sich um einen legitimen Zugriff auf eine Ressource handelt,

72
00:06:06,920 --> 00:06:08,800
aber aufgrund der gleichen Ursprungsrichtlinie

73
00:06:08,800 --> 00:06:12,930
wird Ihr Browser das Laden dieser Ressource verweigern?

74
00:06:12,930 --> 00:06:15,790
Jetzt

75
00:06:15,790 --> 00:06:20,220
werden hier, wie ich bereits erwähnt habe, viele Browser ursprungübergreifende HTTP-Anfragen einschränken,

76
00:06:20,220 --> 00:06:26,420
insbesondere diejenigen, die von XMLHttpRequest oder

77
00:06:26,420 --> 00:06:30,570
dem Fetch-Protokoll zum Abrufen von Daten initiiert werden.

78
00:06:30,570 --> 00:06:36,980
Diese sind relevant, wenn wir aus unserem JavaScript-Code auf diese zugreifen.

79
00:06:36,980 --> 00:06:41,950
Unter diesen Umständen ist es also sinnvoll, die Politik mit gleicher Herkunft aufzuzwingen,

80
00:06:41,950 --> 00:06:46,490
aber dann sollten wir eine Möglichkeit haben, die Situation zu umgehen, in der

81
00:06:46,490 --> 00:06:49,980
ein legitimes Ersuchen gestellt werden kann.

82
00:06:49,980 --> 00:06:52,184
Hier

83
00:06:52,184 --> 00:06:56,960
kommt uns der CORS-Ansatz, der Ansatz der Herkunftsübergreifende Ressourcenfreigabe, zu Hilfe.

84
00:06:56,960 --> 00:07:02,021
Dieser CORS ist also ein Mechanismus, der Webservern ermöglicht

85
00:07:02,021 --> 00:07:06,741
, domänenübergreifende Anfragen oder Ursprungsübergreifende Anforderungen auszuführen.

86
00:07:06,741 --> 00:07:10,400
Hier

87
00:07:10,400 --> 00:07:14,375
interagieren der Browser und der Server, von dem aus Sie versuchen, die Ressource zu reparieren, miteinander und

88
00:07:14,375 --> 00:07:20,945
kommen dann zu einer Vereinbarung, die besagt, dass dieser Zugriff akzeptabel und erlaubt ist.

89
00:07:20,945 --> 00:07:23,575
Sobald die Vereinbarung erreicht ist,

90
00:07:23,575 --> 00:07:29,182
kann diese Anfrage von Ihrem Browser erlaubt werden.

91
00:07:29,182 --> 00:07:32,912
Daher interagieren der Browser und der Server miteinander, um

92
00:07:32,912 --> 00:07:38,252
festzustellen, ob dieser Zugriff auf diese Ressource eine akzeptable Situation ist.

93
00:07:38,252 --> 00:07:43,672
Hier wurde also ein neuer Satz von HTTP-Headern

94
00:07:43,672 --> 00:07:49,010
in die HTTP-Antwortnachrichten eingeführt, die von der Serverseite kommen.

95
00:07:49,010 --> 00:07:54,580
Diese Header ermöglichen es den Servern, die Ursprünge zu beschreiben

96
00:07:54,580 --> 00:08:01,690
, auf die der Server vom Browser zugegriffen werden kann.

97
00:08:01,690 --> 00:08:06,760
Und im Gegenzug erkennt der Browser, dass diese Ressourcenzugriffe

98
00:08:06,760 --> 00:08:11,405
akzeptabel sind, um erlaubt zu werden, auch wenn sie gegen die

99
00:08:11,405 --> 00:08:16,230
gleiche Ursprungsrichtlinie, die wir früher gesehen haben, verstoßen.

100
00:08:16,230 --> 00:08:19,876
In diesem Fall haben wir Header wie zum Beispiel

101
00:08:19,876 --> 00:08:24,821
Access-Control-Allow-Origin, Access-Control-Allow-Credentials,

102
00:08:24,821 --> 00:08:29,780
Access-Control-Allow-Headers, Access-Control-Allow-Methods, und

103
00:08:29,780 --> 00:08:35,330
ein paar andere, die der Server verwendet, um den Browser zu informieren, und sagen, dass

104
00:08:35,330 --> 00:08:41,190
dies eine akzeptable Möglichkeit ist, auf die Ressource von der Browserseite.

105
00:08:41,190 --> 00:08:46,970
Und wenn der Browser diese eingehende Antwortnachricht von der Serverseite sieht,

106
00:08:46,970 --> 00:08:52,510
akzeptiert und erlaubt der Browser diese Cross-Origin-Anfrage auszuführen.

107
00:08:52,510 --> 00:08:56,500
Dies bedeutet nun auch, dass der Server so eingerichtet sein sollte, dass er

108
00:08:56,500 --> 00:09:01,230
mit diesen Header-Feldern und

109
00:09:01,230 --> 00:09:06,800
den Header-Informationen, die in der Antwortnachricht von der Serverseite enthalten sind, antworten kann.

110
00:09:06,800 --> 00:09:11,424
Nun, hier teilen wir alle Cross-Origin-Anfragen in

111
00:09:11,424 --> 00:09:13,260
mehrere Kategorien auf.

112
00:09:13,260 --> 00:09:18,495
Wir haben die erste ist die einfache Cross-Site-Anfrage.

113
00:09:18,495 --> 00:09:22,780
In einfachen Cross-Site-Anfragen verwenden Sie möglicherweise das GET oder den

114
00:09:22,780 --> 00:09:25,410
POST mit dem Anforderungstext.

115
00:09:25,410 --> 00:09:30,180
Aber wenn Sie den POST verwenden, sollte Ihr Anfragetext

116
00:09:30,180 --> 00:09:34,688
entweder application/x-www-URLEncoded

117
00:09:34,688 --> 00:09:39,305
oder multipart/form-data oder text/plain enthalten.

118
00:09:39,305 --> 00:09:44,805
Dann wird es als eine einfache siteübergreifende Anfrage behandelt und

119
00:09:44,805 --> 00:09:47,625
in diesem Fall sind keine benutzerdefinierten Header zulässig.

120
00:09:47,625 --> 00:09:52,955
In diesem Fall ist es also akzeptabel, dass der Server den Client informiert und

121
00:09:52,955 --> 00:09:57,520
sagt, dass dies erlaubt ist und der Browser solche Anfragen zulassen sollte.

122
00:09:57,520 --> 00:10:01,700
Zum Beispiel für weit verbreitete Ressourcen, wie zum Beispiel,

123
00:10:01,700 --> 00:10:05,830
wenn Sie eine GET-Anfrage an einen Server ausführen, um die Daten abzurufen, um die

124
00:10:05,830 --> 00:10:10,580
Benutzeroberfläche zu konstruieren, dann ist die GET-Anforderung möglicherweise akzeptabel,

125
00:10:10,580 --> 00:10:14,400
unabhängig davon, aus welchem Ursprung diese Anforderung stammt.

126
00:10:14,400 --> 00:10:17,350
In diesem Fall antwortet Ihr Server dem Client und

127
00:10:17,350 --> 00:10:23,250
sagt Access-Conrol-Allow-Origin mit diesem Platzhalterstern,

128
00:10:23,250 --> 00:10:27,830
was bedeutet, dass jeder Ursprung, der die Anfrage stammt, akzeptabel ist und

129
00:10:27,830 --> 00:10:33,540
der Browser die Anforderung an diesen Server ausführen lassen sollte.

130
00:10:33,540 --> 00:10:38,020
Und jetzt können Sie auch den Zugriff auf den Ursprung einschränken.

131
00:10:38,020 --> 00:10:44,440
In diesem Fall können Sie ausdrücklich sagen, dass, wenn der Ursprung

132
00:10:44,440 --> 00:10:50,090
eine bestimmte Website ist, es akzeptabel ist, diese Anfrage zu bearbeiten.

133
00:10:50,090 --> 00:10:55,940
Der Browser sieht also, dass das Senden von Anfragen

134
00:10:55,940 --> 00:11:01,230
mit dieser bestimmten Ursprungswebsite in der Anfrage akzeptabel ist und

135
00:11:01,230 --> 00:11:03,830
wir erlauben die Cross-Origin-Anfrage.

136
00:11:03,830 --> 00:11:08,790
So können Sie steuern, wie der Ursprung

137
00:11:08,790 --> 00:11:12,870
in der Anforderungsnachricht angegeben wird, die von der Clientseite kommt.

138
00:11:12,870 --> 00:11:17,500
So ist der Server in der Lage, solche Anfragen zu akzeptieren.

139
00:11:17,500 --> 00:11:23,094
Bestimmte andere Anfragen würden unter die Kategorie der vorangestellten Anfragen fallen.

140
00:11:23,094 --> 00:11:27,750
In der vordefinierten Anforderung erwarten Sie, dass der Client vor dem

141
00:11:27,750 --> 00:11:32,380
Senden der tatsächlichen Anforderung eine Preflight-Anfrage sendet,

142
00:11:32,380 --> 00:11:37,260
was bedeutet, dass er den Server kontaktiert, um

143
00:11:37,260 --> 00:11:41,380
Informationen vom Server zu erhalten, bevor die eigentliche Anforderung ausgegeben wird.

144
00:11:41,380 --> 00:11:46,580
Dies ist insbesondere der Fall, wenn Sie PUT- und DELETE-Anforderungen ausgeben,

145
00:11:46,580 --> 00:11:52,160
da PUT- und DELETE-Anforderungen Änderungen auf der Serverseite verursachen können.

146
00:11:52,160 --> 00:11:58,100
Daher ist jede Methode, die Nebenwirkungen auf die Daten des Servers verursacht, wie die PUT- und

147
00:11:58,100 --> 00:12:03,538
die DELETE-Anfrage, speziell dazu verpflichtet, dem Preflight-Ansatz zu folgen. Beim

148
00:12:03,538 --> 00:12:08,276
Preflight-Ansatz besteht die Idee, dass der Client

149
00:12:08,276 --> 00:12:12,919
zuerst eine HTTP OPTIONS-Anfrage an die Serverseite sendet, und

150
00:12:12,919 --> 00:12:19,174
als Antwort auf diese OPTIONS-Anforderungsnachricht von der Clientseite

151
00:12:19,174 --> 00:12:24,864
antwortet der Server mit den entsprechenden Access-Control-Allow-Headers,

152
00:12:24,864 --> 00:12:31,504
Access-Control-Allow-Origin, und Access-Control-Allow-Credentials

153
00:12:31,504 --> 00:12:36,350
Header-Informationen in der Antwort auf eine OPTIONS-Nachricht.

154
00:12:36,350 --> 00:12:42,359
Danach entscheidet der Kunde, ob er die Cross-Origin-Anforderung ausgeben kann oder

155
00:12:42,359 --> 00:12:48,870
nicht, basierend auf der Antwort auf die OPTIONS-Preflight-Anfrage, die der Client gesendet hat.

156
00:12:48,870 --> 00:12:53,410
Hier müssen Sie also zwei Schritte durchlaufen, bevor Ihre Anfrage von der

157
00:12:53,410 --> 00:12:57,205
Serverseite zugelassen und gewartet werden kann.

158
00:12:58,340 --> 00:13:03,230
Eine dritte Kategorie von CORS-Anforderungen würde sogenannte Anforderungen mit Anmeldeinformationen sein,

159
00:13:03,230 --> 00:13:07,900
bei denen Sie erwarten, dass der Client Anmeldeinformationen in den Header

160
00:13:07,900 --> 00:13:09,608
der Anforderungsnachricht einschließt.

161
00:13:09,608 --> 00:13:13,518
Also die Anfragen, die von Cookies begleitet werden, zum Beispiel zum

162
00:13:13,518 --> 00:13:19,040
Erkennen der Sitzung auf der Serverseite, oder irgendeine Art von

163
00:13:19,040 --> 00:13:24,440
HTTP-Authentifizierungsinformationen im Autorisierungs-Header in der Anforderungsnachricht.

164
00:13:24,440 --> 00:13:27,843
In diesem Fall muss der Server mit

165
00:13:27,843 --> 00:13:32,460
Access-Control-Allow-Credentials antworten: true auf der Clientseite.

166
00:13:32,460 --> 00:13:37,920
In diesem Fall antwortet der Server damit und

167
00:13:37,920 --> 00:13:41,070
dann wird der Client berechtigt sein, seine

168
00:13:41,070 --> 00:13:45,720
Anmeldeinformationen in der eingehenden Anfrage von der Client-Seite zu senden.

169
00:13:45,720 --> 00:13:50,430
In diesem Fall darf der Access-Control-Allow-Origin nicht

170
00:13:50,430 --> 00:13:56,550
die Platzhalterkarte, den Stern, in der Antwortnachricht enthalten.

171
00:13:56,550 --> 00:14:00,770
Es wird erwartet, dass explizit der Ursprung angegeben wird

172
00:14:00,770 --> 00:14:03,450
, zu dem die Anforderung initiiert werden kann.

173
00:14:04,500 --> 00:14:08,235
Nun können wir natürlich viel von der Arbeit implementieren,

174
00:14:08,235 --> 00:14:13,796
was wir auf der Serverseite tun müssen, indem wir unsere eigene Middleware implementieren, wenn wir uns dafür

175
00:14:13,796 --> 00:14:19,260
entscheiden, die CORS-bezogenen Antworten von der Serverseite zu behandeln.

176
00:14:19,260 --> 00:14:23,570
Es ist sehr einfach, wie wir in dem Code gesehen haben, den wir implementiert haben.

177
00:14:23,570 --> 00:14:34,800
Natürlich ist dies eine Möglichkeit, CORS-bezogene Antworten von der Serverseite zu

178
00:14:34,800 --> 00:14:40,470
behandeln, aber zum Glück haben wir ein spezifisches CORS NodeModule, das genau so konzipiert ist, wie es

179
00:14:40,470 --> 00:14:44,920
der Server tun muss, um die CORS-Anforderungen zu erfüllen.

180
00:14:44,920 --> 00:14:50,790
Das CORS NodeModule ermöglicht es uns, das CORS auf der Serverseite zu konfigurieren,

181
00:14:50,790 --> 00:14:55,810
einschließlich der Angabe

182
00:14:55,810 --> 00:15:01,010
von Ursprungsinformationen, wo die Anmeldeinformationen akzeptiert werden, und viele andere Informationen, so dass Sie den Server so konfigurieren können,

183
00:15:01,010 --> 00:15:05,630
dass er CORS-bezogene Antworten verarbeiten kann, die er geben muss an

184
00:15:05,630 --> 00:15:09,480
den Browser als Antwort auf die Anforderungsnachricht.

185
00:15:09,480 --> 00:15:15,750
Um das CORS NodeModule zu installieren, sehen Sie natürlich npm install cors,

186
00:15:15,750 --> 00:15:22,280
und konfigurieren Sie dann die CORS Middleware in Ihrer Express-Anwendung.

187
00:15:23,430 --> 00:15:28,940
Das CORS-Modul selbst bietet eine sehr einfache Möglichkeit, CORS zu aktivieren.

188
00:15:28,940 --> 00:15:35,970
Sie können einfach die App verwenden CORS mit leeren Klammern einschließen, und

189
00:15:35,970 --> 00:15:41,370
das bedeutet im Wesentlichen, dass Sie Ihren Server öffnen, und es wird mit

190
00:15:41,370 --> 00:15:47,180
dem Access-Control-Allow-Origin mit dem Wildcard-Stern auf jede eingehende Anfrage antworten.

191
00:15:47,180 --> 00:15:51,940
Wenn Sie jedoch Ihren Server konfigurieren, möchten Sie möglicherweise mehr Kontrolle darüber haben, so

192
00:15:51,940 --> 00:15:57,190
dass wir zusätzliche Optionen für den CORS angeben können.

193
00:15:57,190 --> 00:16:02,790
Und nicht nur das, Sie können CORS-Handling

194
00:16:02,790 --> 00:16:06,810
für verschiedene Routen innerhalb Ihrer Serverseite unterschiedlich auferlegen.

195
00:16:06,810 --> 00:16:12,320
Wie wir in der Übung sehen werden, werden wir verschiedene CORS-Anforderungen für

196
00:16:12,320 --> 00:16:17,540
die verschiedenen Routen auf unserer Serverseite auferlegen, und dies alles wird durch die Verwendung

197
00:16:17,540 --> 00:16:22,690
verschiedener Konfigurationsoptionen konfiguriert, die das CORS NodeModule für uns unterstützt.

198
00:16:22,690 --> 00:16:28,620
Mit dem CORS NodeModule ist es daher sehr einfach, Ihren Server so einzurichten, dass er

199
00:16:28,620 --> 00:16:34,020
alle ursprungsübergreifenden Anfragen verarbeitet, die von Ihrer Clientseite

200
00:16:34,020 --> 00:16:39,730
eingehen, und dann mit entsprechenden Header-Informationen auf die Clientseite

201
00:16:39,730 --> 00:16:45,310
mit entsprechenden CORS-Headern in der Antwortnachricht von der Serverseite antworten kann.

202
00:16:45,310 --> 00:16:48,450
Mit diesem schnellen Verständnis von CORS,

203
00:16:48,450 --> 00:16:54,730
ich bin sicher, dass Sie an dieser Stelle mehr Fragen haben als Antworten aus diesem Vortrag.

204
00:16:54,730 --> 00:16:58,960
Wenn Sie jedoch noch viel mehr über CORS erfahren möchten,

205
00:16:58,960 --> 00:17:04,050
habe ich Ihnen am Ende dieser Lektion zusätzliche Ressourcen zur Verfügung gestellt,

206
00:17:04,050 --> 00:17:06,804
die es Ihnen ermöglichen, mehr über CORS selbst zu lesen.

207
00:17:06,804 --> 00:17:11,553
Aber aus der Perspektive dieses Kurses möchten wir unsere

208
00:17:11,553 --> 00:17:15,037
Express-Anwendung konfigurieren, die wir

209
00:17:15,037 --> 00:17:19,150
bisher entwickelt haben, um CORS-bezogene Angelegenheiten auf der Serverseite zu behandeln.

210
00:17:19,150 --> 00:17:24,941
Wir werden also das CORS npm-Modul installieren und

211
00:17:24,941 --> 00:17:30,236
es dann auf verschiedenen Routen innerhalb unseres zusätzlichen Servers konfigurieren.

212
00:17:30,236 --> 00:17:33,629
( MUSIK)