VERTRIEB: 1-800-867-1380

CORS (Cross-Origin Resource Sharing)-Unterstützung für Azure-Speicherdienste

Letzte Aktualisierung: November 2013

Ab Version 2013-08-15 unterstützen die Windows Azure-Speicherdienste CORS (Cross-Origin Resource Sharing) für den BLOB-, Tabellen- und Warteschlangendienst. CORS ist eine HTTP-Funktion, mit der eine Webanwendung, die unter einer Domäne ausgeführt wird, auf Ressourcen einer anderen Domäne zugreifen kann. Webbrowser implementieren eine als same-origin-Richtlinie bekannte Sicherheitseinschränkung, die verhindert, dass eine Website APIs in einer anderen Domäne aufruft. CORS ist eine sichere Methode, um einer Domäne (der Ursprungsdomäne) den Aufruf von APIs in einer anderen Domäne zu ermöglichen. Ausführliche Informationen zu CORS finden Sie in der CORS-Spezifikation.

Sie können CORS-Regeln für jeden der Speicherdienste einzeln festlegen, indem Sie Festlegen von Blob-Diensteigenschaften, Festlegen von Warteschlangendiensteigenschaften und Festlegen von Tabellendiensteigenschaften aufrufen. Nachdem Sie die CORS-Regeln für den Dienst festgelegt haben, wird durch Auswertung einer ordnungsgemäß authentifizierten Anforderung, die von einer anderen Domäne an den Dienst gesendet wurde, ermittelt, ob die Anforderung gemäß den von Ihnen festgelegten Regeln zulässig ist.

noteHinweis
Beachten Sie, dass CORS kein Authentifizierungsmechanismus ist. Jede Anforderung, die bei Aktivierung von CORS für eine Speicherressource ausgeführt wird, muss entweder über eine geeignete Authentifizierungssignatur verfügen oder für eine öffentliche Ressource ausgeführt werden.

Eine CORS-Anforderung von einer Ursprungsdomäne kann aus zwei separaten Anforderungen bestehen:

  • Einer Preflight-Anforderung, durch die die vom Dienst auferlegten CORS-Einschränkungen abfragt werden. Die Preflight-Anforderung ist erforderlich, sofern die Anforderungsmethode keine einfache Methode (d. h. GET, HEAD oder POST) ist.

  • Die für die gewünschte Ressource ausgeführte tatsächliche Anforderung.

Durch die Preflight-Anforderung werden die CORS-Einschränkungen abgerufen, die vom Kontobesitzer für den Speicherdienst festgelegt wurden. Der Webbrowser (oder ein anderer Benutzer-Agent) übermittelt eine OPTIONS-Anforderung, die die Anforderungsheader, die Methode und die Ursprungsdomäne enthält. Der Speicherdienst wertet den gewünschten Vorgang anhand eines vorkonfigurierten CORS-Regelsatzes aus, in dem festgelegt ist, welche Ursprungsdomänen, Anforderungsmethoden und Anforderungsheader für eine tatsächliche, an eine Speicherressource gerichtete Anforderung angegeben werden können.

Wenn CORS für den Dienst aktiviert ist, und es eine CORS-Regel gibt, die mit der Preflight-Anforderung übereinstimmt, antwortet der Dienst mit dem Statuscode 200 (OK) und schließt die erforderlichen Access-Control-Header in die Antwort ein.

Wenn CORS nicht für den Dienst aktiviert ist bzw. keine CORS-Regel mit der Preflight-Anforderung übereinstimmt, antwortet der Dienst mit dem Statuscode 403 (Verboten).

Wenn die erforderlichen CORS-Header (der Origin-Header und der Access-Control-Request-Methode-Header) nicht in der OPTIONS-Anforderung enthalten sind, antwortet der Dienst mit dem Statuscode 400 (Ungültige Anforderung).

Beachten Sie, dass eine Preflight-Anforderung für den Dienst (BLOB, Warteschlange oder Tabelle) und nicht für die angeforderte Ressource ausgewertet wird. Der Kontobesitzer muss CORS in den Kontodiensteigenschaften aktiviert haben, damit die Anforderung erfolgreich ist.

Nachdem die Preflight-Anforderung akzeptiert und die Antwort zurückgegeben wurde, sendet der Browser die tatsächliche Anforderung an die Speicherressource. Wenn die Preflight-Anforderung zurückgewiesen wird, wird die tatsächliche Anforderung vom Browser sofort abgelehnt.

Die tatsächliche Anforderung wird als normale Anforderung für den Speicherdienst behandelt. Wenn der Origin-Header vorhanden ist, deutet dies darauf hin, dass die Anforderung eine CORS-Anforderung ist und dass der Dienst diese mit den CORS-Regeln abgleicht. Wenn eine Übereinstimmung gefunden wird, werden die Access-Control-Header der Antwort hinzugefügt und an den Client zurückgesendet. Wenn keine Übereinstimmung gefunden wird, werden die CORS-Access-Control-Header nicht zurückgegeben.

CORS-Regeln werden auf Dienstebene festgelegt, sodass Sie CORS für jeden Dienst (BLOB, Warteschlange oder Tabelle) separat aktivieren oder deaktivieren müssen. CORS ist standardmäßig für jeden Dienst deaktiviert. Um CORS zu aktivieren, müssen Sie die entsprechenden Diensteigenschaften mithilfe von Version 2013-08-15 oder höher festlegen und den Diensteigenschaften CORS-Regeln hinzufügen. Ausführliche Informationen dazu, wie Sie CORS für einen Dienst aktivieren oder deaktivieren und wie Sie CORS-Regeln festlegen, finden Sie unter Festlegen von Blob-Diensteigenschaften, Festlegen von Tabellendiensteigenschaften und Festlegen von Warteschlangendiensteigenschaften.

Im Folgenden sehen Sie ein Beispiel für eine einzelne CORS-Regel, die in einem Vorgang zum Festlegen von Diensteigenschaften angegeben wird:

<Cors>    
      <CorsRule>
            <AllowedOrigins>http://www.contoso.com, http://www.fabrikam.com</AllowedOrigins>
            <AllowedMethods>PUT,GET</AllowedMethods>
            <AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders>
            <ExposedHeaders>x-ms-meta-*</ExposedHeaders>
            <MaxAgeInSeconds>200</MaxAgeInSeconds>
    </CorsRule>
<Cors>

Jedes in der CORS-Regel enthaltene Element wird unten beschrieben:

  • AllowedOrigins: Die Ursprungsdomänen, die über CORS eine Anforderung an den Speicherdienst richten dürfen. Die Ursprungsdomäne ist die Domäne, von der die Anforderung stammt. Beachten Sie, dass die Groß-/Kleinschreibung der Ursprungsdomäne genau mit der der Ursprungsdomäne übereinstimmen muss, die der Benutzer-Agent an den Dienst sendet. Sie können auch das Platzhalterzeichen "*" verwenden, um allen Ursprungsdomänen die Ausführung von CORS-Anforderungen zu erlauben. Im vorangehenden Beispiel können die Domänen http://www.contoso.com und http://www.fabrikam.com CORS-Anforderungen für den Dienst ausführen.

  • AllowedMethods: Die Methoden (HTTP-Anforderungsverben), die die Ursprungsdomäne für eine CORS-Anforderung verwenden kann. Im vorangehenden Beispiel sind PUT- und GET-Anforderungen zulässig.

  • AllowedHeaders: Die Anforderungsheader, die die Ursprungsdomäne für die CORS-Anforderung angeben kann. Im vorangehenden Beispiel sind alle Metadatenheader zulässig, die mit x-ms-meta-data, x-ms-meta-target und x-ms-meta-abc beginnen. Das Platzhalterzeichen "*" zeigt an, dass beliebige Header, die mit dem angegebenen Präfix beginnen, zulässig sind.

  • ExposedHeaders: Die Antwortheader, die in der Antwort an die CORS-Anforderung gesendet und vom Browser gegenüber dem Anforderungsaussteller verfügbar gemacht werden können. Im vorangehenden Beispiel wird der Browser angewiesen, beliebige Header, die mit x-ms-meta beginnen, verfügbar zu machen.

  • MaxAgeInSeconds: Die maximale Zeit, über die die OPTIONS-Preflight-Anforderung vom Browser zwischengespeichert werden soll.

Die Angabe von Headern mit Präfix wird von den Windows Azure-Speicherdiensten sowohl für das AllowedHeaders-Element als auch für das ExposedHeaders-Element unterstützt. Um eine Headerkategorie zuzulassen, können Sie für diese Kategorie ein gemeinsames Präfix angeben. Wenn Sie z. B. x-ms-meta* als Header mit Präfix angeben, wird eine Regel erstellt, durch die alle Header abgeglichen werden, die mit x-ms-meta beginnen.

Für CORS-Regeln gelten die folgenden Einschränkungen:

  • Sie können bis zu fünf CORS-Regeln pro Speicherdienst (BLOB, Tabelle und Warteschlange) angeben.

  • Die maximale Größe aller Einstellungen für CORS-Regeln in der Anforderung sollte 2 KB nicht überschreiten, XML-Tags sind ausgeschlossen.

  • Die Länge eines zulässigen Headers oder Ursprungs bzw. eines verfügbar gemachten Headers sollte maximal 256 Zeichen betragen.

  • Zulässige und verfügbar gemachte Header können in folgender Form vorkommen:

    • Literale Header, bei denen der genaue Headername angegeben ist, z. B. x-ms-meta-processed. In der Anforderung können maximal 64 literale Header angegeben werden.

    • Header mit Präfix, bei denen ein Präfix des Headers angegeben ist, z. B. x-ms-meta-data*. Wird auf diese Weise ein Präfix angegeben, sind alle Header zulässig bzw. werden alle Header verfügbar gemacht, die mit dem angegebenen Präfix beginnen. In der Anforderung können maximal zwei Header mit Präfix angegeben werden.

  • Die im AllowedMethods-Element angegebenen Methoden (oder HTTP-Verben) müssen den Methoden entsprechen, die von den APIS der Windows Azure-Speicherdienste unterstützt werden. Unterstützte Methoden sind DELETE, GET, HEAD, MERGE, POST, OPTIONS und PUT.

Wenn ein Speicherdienst eine Preflight-Anforderung oder eine tatsächliche Anforderung empfängt, wertet er diese Anforderung im entsprechenden Vorgang zum Festlegen von Diensteigenschaften anhand der CORS-Regeln aus, die Sie für den Dienst festgelegt haben. CORS-Regeln werden in der Reihenfolge ausgewertet, in der sie im Anforderungstext des Vorgangs zum Festlegen von Diensteigenschaften definiert wurden.

CORS-Regeln werden wie folgt ausgewertet:

  1. Zunächst wird die Ursprungsdomäne der Anforderung anhand der Domänen überprüft, die für das AllowedOrigins-Element aufgelistet sind. Wenn die Ursprungsdomäne in der Liste enthalten ist bzw. alle Domänen mittels Platzhalterzeichen "*" zulässig sind, dann wird die Regelauswertung fortgesetzt. Wenn die Ursprungsdomäne nicht enthalten ist, tritt ein Anforderungsfehler auf.

  2. Als Nächstes wird die Methode (oder das HTTP-Verb) der Anforderung anhand der Methoden überprüft, die im AllowedMethods-Element aufgelistet sind. Wenn die Methode in der Liste enthalten ist, dann wird die Regelauswertung fortgesetzt; andernfalls ist die Anforderung nicht erfolgreich.

  3. Wenn die Anforderung mit einer Regel in deren Ursprungsdomäne und der zugehörigen Methode übereinstimmt, wird diese Regel zur Verarbeitung der Anforderung ausgewählt, und es werden keine weiteren Regeln ausgewertet. Damit die Anforderung erfolgreich ausgeführt werden kann, müssen jedoch erst die für die Anforderung angegebenen Header anhand der Header überprüft werden, die im AllowedHeaders-Element aufgelistet sind. Wenn die gesendeten Header nicht den zulässigen Headern entsprechen, tritt ein Anforderungsfehler auf.

Da die Regeln in der Reihenfolge verarbeitet werden, in der sie im Anforderungstext aufgeführt sind, wird empfohlen, die restriktivsten Regeln für die obersten Ursprungsdomänen in der Liste festzulegen, damit diese zuerst ausgewertet werden. Geben Sie weniger restriktive Regeln – z. B. eine, die alle Ursprungsdomänen zulässt – für Ursprungsdomänen am Ende der Liste an.

Im folgenden Beispiel wird ein partieller Anforderungstext für einen Vorgang angezeigt, durch den CORS-Regeln für die Speicherdienste festgelegt werden. Ausführliche Informationen zum Erstellen der Anforderung finden Sie unter Festlegen von Blob-Diensteigenschaften, Festlegen von Warteschlangendiensteigenschaften und Festlegen von Tabellendiensteigenschaften.

<Cors>
    <CorsRule>
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>
        <AllowedMethods>PUT,HEAD</AllowedMethods>
        <MaxAgeInSeconds>5</MaxAgeInSeconds>
        <ExposedHeaders>x-ms-*</ExposedHeaders>
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>
    </CorsRule>
    <CorsRule>
        <AllowedOrigins>*</AllowedOrigins>
        <AllowedMethods>PUT,GET</AllowedMethods>
        <MaxAgeInSeconds>5</MaxAgeInSeconds>
        <ExposedHeaders>x-ms-*</ExposedHeaders>
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>
    </CorsRule>
    <CorsRule>
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>
        <AllowedMethods>GET</AllowedMethods>
        <MaxAgeInSeconds>5</MaxAgeInSeconds>
        <ExposedHeaders>x-ms-*</ExposedHeaders>
        <AllowedHeaders>x-ms-client-request-id</AllowedHeaders>
    </CorsRule>
</Cors>

Betrachten Sie als Nächstes die folgenden CORS-Anforderungen:

 

Request

Response

Method

Origin

Request headers

Rule Match

Result

PUT

http://www.contoso.com

x-ms-blob-content-type

Erste Regel

Erfolgreich

GET

http://www.contoso.com

x-ms-blob-content-type

Zweite Regel

Erfolgreich

GET

http://www.contoso.com

x-ms-client-request-id

Zweite Regel

Fehler

Die erste Anforderung stimmt mit der ersten Regel überein – die Ursprungsdomäne fällt unter die zulässigen Ursprungsdomänen, die Methode unter die zulässigen Methoden und der Header unter die zulässigen Header – sie wird somit erfolgreich ausgeführt.

Die zweite Anforderung stimmt nicht mit der ersten Regel überein, weil die Methode nicht unter die zulässigen Methoden fällt. Sie stimmt jedoch mit der zweiten Regel überein und wird somit erfolgreich ausgeführt.

Die dritte Anforderung stimmt mit der zweiten Regel in ihrer Ursprungsdomäne und der Methode überein, sodass keine weiteren Regeln ausgewertet werden. Allerdings ist der x-ms-client-request-id-Header gemäß der zweiten Regel nicht zulässig, sodass die Anforderung nicht erfolgreich ist. Dies gilt, obwohl die Anforderung gemäß der Semantik der dritten Regel erfolgreich gewesen wäre.

noteHinweis
Obwohl in diesem Beispiel eine weniger restriktive Regel vor einer restriktiveren Regel angewendet wird, empfiehlt es sich im Allgemeinen, die restriktivsten Regeln an den Anfang zu stellen.

Der Vary-Header ist ein HTTP/1.1-Standardheader, der aus einer Gruppe von Anforderungsheaderfeldern besteht, über die dem Browser bzw. Benutzer-Agent mitgeteilt wird, welche Kriterien der Server zur Verarbeitung der Anforderung ausgewählt hat. Der Vary-Header wird hauptsächlich von Proxys, Browsern und CDNs für das Zwischenspeichern verwendet. Anhand des Headers wird ermittelt, wie die Antwort zwischengespeichert werden soll. Ausführliche Informationen finden Sie in der Spezifikation zum Vary-Header.

Wenn der Browser oder ein anderer Benutzer-Agent die Antwort von einer CORS-Anforderung zwischenspeichert, wird die Ursprungsdomäne als zulässige Ursprungsdomäne zwischengespeichert. Wenn eine zweite Domäne die Anforderung für eine Speicherressource ausgibt, während der Cache aktiv ist, ruft der Benutzer-Agent die zwischengespeicherte Ursprungsdomäne ab. Die zweite Domäne stimmt nicht mit der zwischengespeicherten Domäne überein, sodass die ansonsten erfolgreich ausgeführte Anforderung fehlschlägt. In bestimmten Fällen wird der Vary-Header vom Windows Azure-Speicher auf Origin festgelegt, um den Benutzer-Agent anzuweisen, die nachfolgende CORS-Anforderung an den Dienst zu senden, wenn sich die anfordernde Domäne von der zwischengespeicherten Ursprungsdomäne unterscheidet.

Der Windows Azure-Speicher legt den Vary-Header für tatsächliche GET/HEAD-Anforderungen in den folgenden Fällen auf Origin fest:

  • Die Ursprungsdomäne der Anforderung stimmt genau mit der zulässigen Ursprungsdomäne überein, die von einer CORS-Regel definiert wird. Eine genaue Übereinstimmung wird nur erzielt, wenn die CORS-Regel kein Platzhalterzeichen "*" enthält.

  • Es gibt keine Regel, die mit der Ursprungsdomäne der Anforderung übereinstimmt, CORS ist jedoch für den Speicherdienst aktiviert.

Falls eine GET-/HEAD-Anforderung mit einer CORS-Regel übereinstimmt, die alle Ursprungsdomänen zulässt, gibt die Antwort an, dass alle Ursprungsdomänen zulässig sind. Solange der Cache aktiv ist, lässt der Benutzer-Agent nachfolgende Anforderungen von beliebigen Ursprungsdomänen zu.

Bei Anforderungen, die andere Methoden als GET/HEAD verwenden, wird der Vary-Header von den Speicherdiensten nicht festgelegt, da die Antworten auf diese Methoden nicht von den Benutzer-Agent zwischengespeichert werden.

Der folgenden Tabelle können Sie entnehmen, wie der Windows Azure-Speicher in den oben beschriebenen Fällen auf GET-/HEAD-Anforderungen antwortet:

 

Anforderung

Kontoeinstellung und Ergebnis der Regelauswertung

Antwort

Origin-Header für Anforderung vorhanden

CORS-Regel(n) für den Dienst angegeben

Abgleichsregel vorhanden, die alle Ursprungsdomänen zulässt (*)

Abgleichsregel für genaue Übereinstimmung mit Ursprungsdomäne vorhanden

Antwort enthält Vary-Header, der auf "Origin" festgelegt ist

Antwort enthält "Access-Control-Allowed-Origin": "*"

Antwort enthält Access-Control-Exposed-Header

Nein

Nein

Nein

Nein

Nein

Nein

Nein

Nein

Ja

Nein

Nein

Ja

Nein

Nein

Nein

Ja

Ja

Nein

Nein

Ja

Ja

Ja

Nein

Nein

Nein

Nein

Nein

Nein

Ja

Ja

Nein

Ja

Ja

Nein

Ja

Ja

Ja

Nein

Nein

Ja

Nein

Nein

Ja

Ja

Ja

Nein

Nein

Ja

Ja

Erfolgreiche Preflight-Anforderungen werden berechnet, wenn Sie CORS (durch Aufrufen von Festlegen von Blob-Diensteigenschaften, Festlegen von Warteschlangendiensteigenschaften oder Festlegen von Tabellendiensteigenschaften) für einen der Speicherdienste unter Ihrem Konto aktiviert haben. Um die Gebühren zu minimieren, sollten Sie das MaxAgeInSeconds-Element in den CORS-Regeln auf einen hohen Wert festlegen, sodass die Anforderung vom Benutzer-Agent zwischengespeichert wird.

Fehlgeschlagene Preflight-Anforderungen werden nicht berechnet.

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft