CORS-Fehlerbehebung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Die folgenden Themen können bei der Behebung von allgemeinen Problemen mit CORS in Bezug auf S3 hilfreich sein.

Fehler 403 Forbidden: CORS ist für diesen Bucket nicht aktiviert

Der Fehler 403 Forbidden tritt auf, wenn eine ursprungsübergreifende Anfrage an Amazon S3 gesendet wird, CORS jedoch nicht in Ihrem S3-Bucket konfiguriert ist.

Fehler: HTTP/1.1 403 Forbidden CORS Response: CORS is not enabled for this bucket.

Die CORS-Konfiguration ist ein Dokument oder eine Richtlinien mit Regeln, die die Ursprünge, die auf Ihren Bucket zugreifen dürfen, die Vorgänge (HTTP-Methoden), die die einzelnen Ursprünge unterstützen, sowie weitere operationsspezifische Informationen identifizieren. Erfahren Sie, wie Sie CORS auf S3 mithilfe der Amazon S3 S3-Konsole und der REST-API konfigurieren. AWS SDKs Weitere Informationen zu CORS und Beispiele für eine CORS-Konfiguration finden Sie unter Elemente von CORS.

Fehler 403 Forbidden: Diese CORS-Anfrage ist nicht zulässig

Sie erhalten den Fehler 403 Forbidden, wenn eine CORS-Regel in Ihrer CORS-Konfiguration nicht den Daten in Ihrer Anfrage entspricht.

Fehler: HTTP/1.1 403 Forbidden CORS Response: This CORS request is not allowed.

Daher kann der Fehler 403 Forbidden aus mehreren Gründen auftreten:

Für jede von Amazon S3 erhaltene Anfrage benötigen Sie eine CORS-Regel in Ihrer CORS-Konfiguration, die den Daten in Ihrer Anfrage entspricht.

Ursprung ist nicht zulässig

Der Origin-Header in einer CORS-Anfrage an Ihren Bucket muss den Ursprüngen im Element AllowedOrigins Ihrer CORS-Konfiguration entsprechen. Ein Platzhalterzeichen ("*") im Element AllowedOrigins würde allen HTTP-Methoden entsprechen. Weitere Informationen zum Aktualisieren des Elements AllowedOrigins finden Sie unter Cross-Origin Resource Sharing (CORS) konfigurieren.

Wenn beispielsweise nur die Domain http://www.example1.com im Element AllowedOrigins enthalten ist, würde eine von der Domain http://www.example2.com gesendete CORS-Anfrage den Fehler 403 Forbidden erhalten.

Das folgende Beispiel zeigt einen Teil einer CORS-Konfiguration, der die Domäne http://www.example1.com im Element AllowedOrigins enthält.

"AllowedOrigins":[
   "http://www.example1.com"
]

Damit eine von der Domain http://www.example2.com gesendete CORS-Anfrage erfolgreich ist, muss die Domain http://www.example2.com in das Element AllowedOrigins der CORS-Konfiguration aufgenommen werden.

"AllowedOrigins":[
   "http://www.example1.com"
   "http://www.example2.com"
]

Methoden sind nicht zulässig

Die HTTP-Methoden, die in der Access-Control-Request-Method einer CORS-Anfrage an Ihren Bucket angegeben sind, müssen der oder den Methoden entsprechen, die im Element AllowedMethods Ihrer CORS-Konfiguration aufgeführt sind. Ein Platzhalterzeichen ("*") in AllowedMethods würde allen HTTP-Methoden entsprechen. Weitere Informationen zum Aktualisieren des Elements AllowedOrigins finden Sie unter Cross-Origin Resource Sharing (CORS) konfigurieren.

In einer CORS-Konfiguration können Sie im Element AllowedMethods die folgenden Methoden angeben:

Das folgende Beispiel zeigt einen Teil einer CORS-Konfiguration, der die Methode GET im Element AllowedMethods enthält. Nur Anfragen, die die Methode GET enthalten, wären erfolgreich.

"AllowedMethods":[
   "GET"
]

Wenn eine HTTP-Methode (z. B. PUT) in einer CORS-Anfrage verwendet wurde oder in einer Preflight-CORS-Anfrage an Ihren Bucket enthalten war, die Methode jedoch nicht in Ihrer CORS-Konfiguration vorhanden ist, führt die Anfrage zu einem Fehler des Typs 403 Forbidden. Um diese CORS- oder CORS-Preflight-Anfrage zuzulassen, muss die Methode PUT zu Ihrer CORS-Konfiguration hinzugefügt werden.

"AllowedMethods":[
   "GET"
   "PUT"
]

Angeforderte Header sind nicht zulässig

Die im Header Access-Control-Request-Headers einer Preflight-Anfrage aufgeführten Header müssen den Headern im Element AllowedHeaders Ihrer CORS-Konfiguration entsprechen. Eine Liste mit üblichen Headern, die in Anforderungen an Amazon S3 verwendet werden können, finden Sie unter Häufig verwendete Anforderungsheader. Weitere Informationen zum Aktualisieren des Elements AllowedHeaders finden Sie unter Cross-Origin Resource Sharing (CORS) konfigurieren.

Das folgende Beispiel zeigt einen Teil einer CORS-Konfiguration, der den Header Authorization im Element AllowedHeaders enthält. Nur Anfragen für den Header Authorization wären erfolgreich.

"AllowedHeaders":  [
    "Authorization"
]

Wenn ein Header (z. B. Content-MD5) in einer CORS-Anfrage enthalten war, jedoch nicht in Ihrer CORS-Konfiguration vorhanden ist, führt die Anfrage zu einem Fehler des Typs 403 Forbidden. Um diese CORS-Anfrage zuzulassen, muss der Header Content-MD5 zu Ihrer CORS-Konfiguration hinzugefügt werden. Wenn Sie sowohl den Header Authorization als auch den Header Content-MD5 in einer CORS-Anfrage an Ihren Bucket übergeben möchten, stellen Sie sicher, dass beide Header im Element AllowedHeaders Ihrer CORS-Konfiguration enthalten sind.

"AllowedHeaders":  [
    "Authorization"
    "Content-MD5"
]           

Header nicht in der CORS-Antwort gefunden

Das Element ExposeHeaders Ihrer CORS-Konfiguration identifiziert, welche Antwort-Header Sie für Skripts und Anwendungen, die in Browsern ausgeführt werden, als Antwort auf eine CORS-Anfrage zugänglich machen möchten.

Wenn Ihre in Ihrem S3-Bucket gespeicherten Objekte benutzerdefinierte Metadaten (z. B.x-amz-meta-custom-header) zusammen mit den Antwortdaten haben, könnte dieser benutzerdefinierte Header zusätzliche Metadaten oder Informationen enthalten, auf die Sie über Ihren JavaScript clientseitigen Code zugreifen möchten. Standardmäßig blockieren Browser jedoch aus Sicherheitsgründen den Zugriff auf benutzerdefinierte Header. Damit Ihre Client-Seite auf benutzerdefinierte Header zugreifen JavaScript kann, müssen Sie den Header in Ihre CORS-Konfiguration aufnehmen.

Im folgenden Beispiel ist der Header x-amz-meta-custom-header1 im Element ExposeHeaders enthalten. Der Header x-amz-meta-custom-header2 ist nicht im Element ExposeHeaders enthalten und fehlt in der CORS-Konfiguration. In der Antwort würden nur die im Element ExposeHeaders enthaltenen Werte zurückgegeben werden. Hätte die Anfrage den Header x-amz-meta-custom-header2 im Header Access-Control-Expose-Headers enthalten, würde die Antwort trotzdem 200 OK zurückgeben. Es würde jedoch nur der zulässige Header, z. B. x-amz-meta-custom-header, zurückgegeben und in der Antwort angezeigt werden.

"ExposeHeaders":  [
    "x-amz-meta-custom-header1"
]           

Um sicherzustellen, dass alle Header in der Antwort erscheinen, fügen Sie dem Element ExposeHeaders Ihrer CORS-Konfiguration alle zulässigen Header hinzu, wie unten gezeigt.

"ExposeHeaders":  [
    "x-amz-meta-custom-header1",
    "x-amz-meta-custom-header2"
]           

Überlegungen zu CORS in S3-Proxy-Integrationen

Wenn bei Ihnen Fehler auftreten und Sie die CORS-Konfiguration in Ihrem S3-Bucket bereits überprüft haben und die Cross-Origin-Anfrage an Proxys wie gesendet wird, versuchen Sie Folgendes: AWS CloudFront

Einige Proxys bieten vordefinierte Features für CORS-Anfragen. In können Sie beispielsweise eine Richtlinie konfigurieren CloudFront, die die Header enthält

die CORS-Anforderungen (Cross-Origin Resource Sharing) aktivieren, wenn der Ursprung ein Amazon S3 Bucket ist.

Diese Richtlinie hat folgende Einstellungen:

Weitere Informationen finden Sie unter Steuern von Anfragen mit Ursprung mithilfe einer Richtlinie und Verwenden von Richtlinien für verwaltete Anfragen mit Ursprung im CloudFront Entwicklerhandbuch.