[MUSIK]
Lasst uns jetzt in einer CORS-Sprache reden.
Was genau ist das gemeinsame Teilen von Ergebnissen, und
warum ist es relevant, wenn wir Webanwendungen und
hypermobile Anwendungen betrachten, wie wir es in dieser Spezialisierung getan haben?
Wie Sie verstehen, ziehen die meisten Webseiten jetzt Daten von
vielen verschiedenen Websites ein, um eine Webseite zu erstellen.
Nun, um eine strenge Politik des Zugriffs auf Ressourcen von verschiedenen Websites durchzusetzen,
wurde die gleiche Ursprungspolitik von vielen Browsern auferlegt.
Wir werden auf den nächsten Folien ein wenig ausführlicher darüber sprechen, aber
im Zusammenhang mit den Frameworks, die wir in dieser speziellen
Spezialisierung diskutiert haben, wie Angular, Ionic und NativeScript,
werden viele von ihnen Skripte, JavaScript-Code,
die möglicherweise Zugriff auf Ressourcen von verschiedenen Websites.
Und das ist, wo das CORS-Problem sehr leicht auftaucht.
Lassen Sie uns sehen, wie wir dieses Problem in diesem Vortrag und
der folgenden Übung ausführlicher behandeln werden.
Ich habe kurz auf die Politik der gleichen Herkunft angedeutet, die ich mit diesem Vortrag begonnen habe.
Nun ist die gleiche Ursprungsrichtlinie ein Web-App-Sicherheitsmodell,
das einschränkt, wie ein Dokument oder ein Skript, das
von einem Ursprung geladen wird, mit Ressourcen aus einem anderen Ursprung interagiert.
Dies dient dazu, potenziell schädliche Dokumente zu isolieren.
Nun offensichtlich, wenn Sie eine Webseite haben, die Skript,
JavaScript-Code enthält, die auf Ressourcen von einem anderen Ort zugreifen könnte,
könnte potenziell bösartiger Code in Ihre Webseite injiziert werden und
durch den Zugriff auf einen anderen Ursprung als von wo aus Ihre Webseite abgerufen wird.
Nun, das ist der Grund, warum viele Browser diese gleiche Ursprungsrichtlinie auferlegen.
Nun, wenn wir über die gleiche Herkunft sprechen, wie geben wir einen Ursprung an?
In diesem Zusammenhang wird nun ein Ursprung für jede Ressource durch drei Tupel definiert.
Zuerst das Protokoll, das für den Zugriff auf die Ressource verwendet wird.
Zweitens der Hostname der Ressource oder die Domäne dieser Ressource.
Und drittens die Portnummer, unter der auf diese Ressource zugegriffen wird.
So identifizieren wir den Ursprung jeder Ressource.
Ressource könnte in diesem Fall eine HTML-Seite, ein Bild,
JSON-Daten, die von einem REST-API-Endpunkt abgerufen werden, und vieles mehr sein.
Um die gleiche Ursprungspolitik weiter zu erläutern, schauen wir uns ein Beispiel an.
Angenommen, wir haben eine Webseite, die von dieser Website geladen wird, die hier aufgelistet ist
, www.abc.com, und in einem Ordner xyz, und
die page.html wird hier geladen.
Diese Seite kann Links oder sogar JavaScript-Code enthalten, der
XMLHttpRequest für andere Ressourcen auf der Webseite ausgibt.
Nun, in diesem Fall, wenn wir versuchen, auf eine andere URL zuzugreifen, zum
Beispiel, die erste hier aufgelistet, die offensichtlich Sie sehen, stammt
von der gleichen Website, aber von einem anderen Ordner.
Dies ist akzeptabel, da der Ursprung, in diesem Fall
das verwendete Protokoll und die Portnummer, gleich bleibt.
Dies ist also akzeptabel, um auf diese Ressource zuzugreifen.
Ähnlich im zweiten Fall haben wir unter
mehreren Ebenen von Unterordnern eine Ressource, auf die zugegriffen wird.
Aber wieder, da ihr Ursprung gleich bleibt, was akzeptabel ist.
Aber schauen wir uns das dritte Beispiel hier an.
In diesem Beispiel sehen wir, dass wir versuchen, hier mit
dem https-Protokoll auf eine Ressource zuzugreifen, was offensichtlich gegen den gleichen Ursprung Prinzipal verstößt,
da wir ein anderes Protokoll verwenden, um an dieser Stelle auf diese Ressource zuzugreifen.
Das würde also in diesem Fall als Fehler angesehen werden.
Der vierte Fall ist, wo wir auf eine Ressource mit einer anderen Portnummer zugreifen.
Und der fünfte Fall ist, wo wir auf eine Ressource auf einem anderen Host zugreifen.
Nun würden alle diese drei als ungültig markiert oder
können nicht unter dieser gleichen Ursprungsrichtlinie zugegriffen werden.
Wenn Sie also die gleiche Ursprungsrichtlinie für den Zugriff von
Ihrem XMLHttpRequest auferlegen, wären die letzten drei in diesem Fall nicht zulässig.
Aber natürlich gibt es viele Situationen, in denen dieser Website-Designer
tatsächlich Ressourcen auf verschiedenen Websites hosten kann, vielleicht auf verschiedenen Domänen,
und immer noch in der Lage sein, die Daten einzuziehen, um die Webseite
zu konstruieren oder die Webanwendung auszuführen oder um die hybride mobile Anwendung auszuführen .
Um diesen Situationen gerecht zu werden,
ist die Cross-Origin Request Handling eine Methode, die es uns ermöglicht, auf diese Ressourcen zuzugreifen.
Daher betrachten wir eine Anfrage als
Cross-Origin-Anfrage, wenn Sie versuchen, auf eine Ressource von einer anderen Domäne
oder von einer anderen Portnummer oder mit einem anderen Protokoll zuzugreifen.
Wie können wir Situationen berücksichtigen, in denen es sich um einen legitimen Zugriff auf eine Ressource handelt,
aber aufgrund der gleichen Ursprungsrichtlinie
wird Ihr Browser das Laden dieser Ressource verweigern?
Jetzt
werden hier, wie ich bereits erwähnt habe, viele Browser ursprungübergreifende HTTP-Anfragen einschränken,
insbesondere diejenigen, die von XMLHttpRequest oder
dem Fetch-Protokoll zum Abrufen von Daten initiiert werden.
Diese sind relevant, wenn wir aus unserem JavaScript-Code auf diese zugreifen.
Unter diesen Umständen ist es also sinnvoll, die Politik mit gleicher Herkunft aufzuzwingen,
aber dann sollten wir eine Möglichkeit haben, die Situation zu umgehen, in der
ein legitimes Ersuchen gestellt werden kann.
Hier
kommt uns der CORS-Ansatz, der Ansatz der Herkunftsübergreifende Ressourcenfreigabe, zu Hilfe.
Dieser CORS ist also ein Mechanismus, der Webservern ermöglicht
, domänenübergreifende Anfragen oder Ursprungsübergreifende Anforderungen auszuführen.
Hier
interagieren der Browser und der Server, von dem aus Sie versuchen, die Ressource zu reparieren, miteinander und
kommen dann zu einer Vereinbarung, die besagt, dass dieser Zugriff akzeptabel und erlaubt ist.
Sobald die Vereinbarung erreicht ist,
kann diese Anfrage von Ihrem Browser erlaubt werden.
Daher interagieren der Browser und der Server miteinander, um
festzustellen, ob dieser Zugriff auf diese Ressource eine akzeptable Situation ist.
Hier wurde also ein neuer Satz von HTTP-Headern
in die HTTP-Antwortnachrichten eingeführt, die von der Serverseite kommen.
Diese Header ermöglichen es den Servern, die Ursprünge zu beschreiben
, auf die der Server vom Browser zugegriffen werden kann.
Und im Gegenzug erkennt der Browser, dass diese Ressourcenzugriffe
akzeptabel sind, um erlaubt zu werden, auch wenn sie gegen die
gleiche Ursprungsrichtlinie, die wir früher gesehen haben, verstoßen.
In diesem Fall haben wir Header wie zum Beispiel
Access-Control-Allow-Origin, Access-Control-Allow-Credentials,
Access-Control-Allow-Headers, Access-Control-Allow-Methods, und
ein paar andere, die der Server verwendet, um den Browser zu informieren, und sagen, dass
dies eine akzeptable Möglichkeit ist, auf die Ressource von der Browserseite.
Und wenn der Browser diese eingehende Antwortnachricht von der Serverseite sieht,
akzeptiert und erlaubt der Browser diese Cross-Origin-Anfrage auszuführen.
Dies bedeutet nun auch, dass der Server so eingerichtet sein sollte, dass er
mit diesen Header-Feldern und
den Header-Informationen, die in der Antwortnachricht von der Serverseite enthalten sind, antworten kann.
Nun, hier teilen wir alle Cross-Origin-Anfragen in
mehrere Kategorien auf.
Wir haben die erste ist die einfache Cross-Site-Anfrage.
In einfachen Cross-Site-Anfragen verwenden Sie möglicherweise das GET oder den
POST mit dem Anforderungstext.
Aber wenn Sie den POST verwenden, sollte Ihr Anfragetext
entweder application/x-www-URLEncoded
oder multipart/form-data oder text/plain enthalten.
Dann wird es als eine einfache siteübergreifende Anfrage behandelt und
in diesem Fall sind keine benutzerdefinierten Header zulässig.
In diesem Fall ist es also akzeptabel, dass der Server den Client informiert und
sagt, dass dies erlaubt ist und der Browser solche Anfragen zulassen sollte.
Zum Beispiel für weit verbreitete Ressourcen, wie zum Beispiel,
wenn Sie eine GET-Anfrage an einen Server ausführen, um die Daten abzurufen, um die
Benutzeroberfläche zu konstruieren, dann ist die GET-Anforderung möglicherweise akzeptabel,
unabhängig davon, aus welchem Ursprung diese Anforderung stammt.
In diesem Fall antwortet Ihr Server dem Client und
sagt Access-Conrol-Allow-Origin mit diesem Platzhalterstern,
was bedeutet, dass jeder Ursprung, der die Anfrage stammt, akzeptabel ist und
der Browser die Anforderung an diesen Server ausführen lassen sollte.
Und jetzt können Sie auch den Zugriff auf den Ursprung einschränken.
In diesem Fall können Sie ausdrücklich sagen, dass, wenn der Ursprung
eine bestimmte Website ist, es akzeptabel ist, diese Anfrage zu bearbeiten.
Der Browser sieht also, dass das Senden von Anfragen
mit dieser bestimmten Ursprungswebsite in der Anfrage akzeptabel ist und
wir erlauben die Cross-Origin-Anfrage.
So können Sie steuern, wie der Ursprung
in der Anforderungsnachricht angegeben wird, die von der Clientseite kommt.
So ist der Server in der Lage, solche Anfragen zu akzeptieren.
Bestimmte andere Anfragen würden unter die Kategorie der vorangestellten Anfragen fallen.
In der vordefinierten Anforderung erwarten Sie, dass der Client vor dem
Senden der tatsächlichen Anforderung eine Preflight-Anfrage sendet,
was bedeutet, dass er den Server kontaktiert, um
Informationen vom Server zu erhalten, bevor die eigentliche Anforderung ausgegeben wird.
Dies ist insbesondere der Fall, wenn Sie PUT- und DELETE-Anforderungen ausgeben,
da PUT- und DELETE-Anforderungen Änderungen auf der Serverseite verursachen können.
Daher ist jede Methode, die Nebenwirkungen auf die Daten des Servers verursacht, wie die PUT- und
die DELETE-Anfrage, speziell dazu verpflichtet, dem Preflight-Ansatz zu folgen. Beim
Preflight-Ansatz besteht die Idee, dass der Client
zuerst eine HTTP OPTIONS-Anfrage an die Serverseite sendet, und
als Antwort auf diese OPTIONS-Anforderungsnachricht von der Clientseite
antwortet der Server mit den entsprechenden Access-Control-Allow-Headers,
Access-Control-Allow-Origin, und Access-Control-Allow-Credentials
Header-Informationen in der Antwort auf eine OPTIONS-Nachricht.
Danach entscheidet der Kunde, ob er die Cross-Origin-Anforderung ausgeben kann oder
nicht, basierend auf der Antwort auf die OPTIONS-Preflight-Anfrage, die der Client gesendet hat.
Hier müssen Sie also zwei Schritte durchlaufen, bevor Ihre Anfrage von der
Serverseite zugelassen und gewartet werden kann.
Eine dritte Kategorie von CORS-Anforderungen würde sogenannte Anforderungen mit Anmeldeinformationen sein,
bei denen Sie erwarten, dass der Client Anmeldeinformationen in den Header
der Anforderungsnachricht einschließt.
Also die Anfragen, die von Cookies begleitet werden, zum Beispiel zum
Erkennen der Sitzung auf der Serverseite, oder irgendeine Art von
HTTP-Authentifizierungsinformationen im Autorisierungs-Header in der Anforderungsnachricht.
In diesem Fall muss der Server mit
Access-Control-Allow-Credentials antworten: true auf der Clientseite.
In diesem Fall antwortet der Server damit und
dann wird der Client berechtigt sein, seine
Anmeldeinformationen in der eingehenden Anfrage von der Client-Seite zu senden.
In diesem Fall darf der Access-Control-Allow-Origin nicht
die Platzhalterkarte, den Stern, in der Antwortnachricht enthalten.
Es wird erwartet, dass explizit der Ursprung angegeben wird
, zu dem die Anforderung initiiert werden kann.
Nun können wir natürlich viel von der Arbeit implementieren,
was wir auf der Serverseite tun müssen, indem wir unsere eigene Middleware implementieren, wenn wir uns dafür
entscheiden, die CORS-bezogenen Antworten von der Serverseite zu behandeln.
Es ist sehr einfach, wie wir in dem Code gesehen haben, den wir implementiert haben.
Natürlich ist dies eine Möglichkeit, CORS-bezogene Antworten von der Serverseite zu
behandeln, aber zum Glück haben wir ein spezifisches CORS NodeModule, das genau so konzipiert ist, wie es
der Server tun muss, um die CORS-Anforderungen zu erfüllen.
Das CORS NodeModule ermöglicht es uns, das CORS auf der Serverseite zu konfigurieren,
einschließlich der Angabe
von Ursprungsinformationen, wo die Anmeldeinformationen akzeptiert werden, und viele andere Informationen, so dass Sie den Server so konfigurieren können,
dass er CORS-bezogene Antworten verarbeiten kann, die er geben muss an
den Browser als Antwort auf die Anforderungsnachricht.
Um das CORS NodeModule zu installieren, sehen Sie natürlich npm install cors,
und konfigurieren Sie dann die CORS Middleware in Ihrer Express-Anwendung.
Das CORS-Modul selbst bietet eine sehr einfache Möglichkeit, CORS zu aktivieren.
Sie können einfach die App verwenden CORS mit leeren Klammern einschließen, und
das bedeutet im Wesentlichen, dass Sie Ihren Server öffnen, und es wird mit
dem Access-Control-Allow-Origin mit dem Wildcard-Stern auf jede eingehende Anfrage antworten.
Wenn Sie jedoch Ihren Server konfigurieren, möchten Sie möglicherweise mehr Kontrolle darüber haben, so
dass wir zusätzliche Optionen für den CORS angeben können.
Und nicht nur das, Sie können CORS-Handling
für verschiedene Routen innerhalb Ihrer Serverseite unterschiedlich auferlegen.
Wie wir in der Übung sehen werden, werden wir verschiedene CORS-Anforderungen für
die verschiedenen Routen auf unserer Serverseite auferlegen, und dies alles wird durch die Verwendung
verschiedener Konfigurationsoptionen konfiguriert, die das CORS NodeModule für uns unterstützt.
Mit dem CORS NodeModule ist es daher sehr einfach, Ihren Server so einzurichten, dass er
alle ursprungsübergreifenden Anfragen verarbeitet, die von Ihrer Clientseite
eingehen, und dann mit entsprechenden Header-Informationen auf die Clientseite
mit entsprechenden CORS-Headern in der Antwortnachricht von der Serverseite antworten kann.
Mit diesem schnellen Verständnis von CORS,
ich bin sicher, dass Sie an dieser Stelle mehr Fragen haben als Antworten aus diesem Vortrag.
Wenn Sie jedoch noch viel mehr über CORS erfahren möchten,
habe ich Ihnen am Ende dieser Lektion zusätzliche Ressourcen zur Verfügung gestellt,
die es Ihnen ermöglichen, mehr über CORS selbst zu lesen.
Aber aus der Perspektive dieses Kurses möchten wir unsere
Express-Anwendung konfigurieren, die wir
bisher entwickelt haben, um CORS-bezogene Angelegenheiten auf der Serverseite zu behandeln.
Wir werden also das CORS npm-Modul installieren und
es dann auf verschiedenen Routen innerhalb unseres zusätzlichen Servers konfigurieren.
( MUSIK)