wake-up-neo.com

API Gateway CORS: Kein 'Access-Control-Allow-Origin'-Header

Obwohl CORS über API-Gateway eingerichtet wurde und der Access-Control-Allow-Origin-Header festgelegt ist, wird beim Versuch, die API von AJAX innerhalb von Chrome aufzurufen, die folgende Fehlermeldung angezeigt:

XMLHttpRequest kann http://XXXXX.execute-api.us-west-2.amazonaws.com/beta/YYYYY nicht laden. Auf der angeforderten Ressource ist kein Header "Access-Control-Allow-Origin" vorhanden. Origin 'null' hat daher keinen Zugriff. Die Antwort hatte den HTTP-Statuscode 403.

Ich habe versucht, die URL über Postman zu erhalten, und es zeigt, dass der obige Header erfolgreich übergeben wurde:

Passed headers

Und aus der Antwort von OPTIONS:

Response headers

Wie kann ich meine API vom Browser aus aufrufen, ohne auf JSON-P zurückzugreifen?

42
makinbacon

Ich habe das gleiche Problem. Ich habe 10 Stunden gebraucht, um es herauszufinden. 

https://serverless.com/framework/docs/providers/aws/events/apigateway/

// handler.js

'use strict';

module.exports.hello = function(event, context, callback) {

const response = {
  statusCode: 200,
  headers: {
    "Access-Control-Allow-Origin" : "*", // Required for CORS support to work
    "Access-Control-Allow-Credentials" : true // Required for cookies, authorization headers with HTTPS 
  },
  body: JSON.stringify({ "message": "Hello World!" })
};

callback(null, response);
};
61
riseres

Wenn noch jemand in diese Richtung läuft, konnte ich die Ursache in meiner Anwendung ausfindig machen. 

Wenn Sie ein API-Gateway mit benutzerdefinierten Autorisierern ausführen, sendet API-Gateway eine 401 oder 403 zurück, bevor es tatsächlich Ihren Server erreicht. Standardmäßig ist API-Gateway NICHT für CORS konfiguriert, wenn 4xx von einem benutzerdefinierten Autorisierungsprogramm zurückgegeben wird.

Auch - wenn Sie aus einer Anforderung, die über API Gateway ausgeführt wird, den Statuscode 0 oder 1 erhalten, liegt dies wahrscheinlich an Ihrem Problem.

Um dies zu beheben, gehen Sie in der API-Gateway-Konfiguration zu "Gateway Responses", erweitern Sie "Default 4XX" und fügen Sie dort einen CORS-Konfigurationsheader hinzu. d.h.

Access-Control-Allow-Origin: '*'

Stellen Sie sicher, dass Sie Ihr Gateway erneut bereitstellen - und voila!

37
Gabriel Doty

Habe mein Beispiel am Laufen: Ich gerade eingefügt 'Zugriffskontrolle-Zulassen-Ursprung': '*', innerhalb Kopfzeilen: {} in der generierten Lambda-Funktion des Knotens. Ich habe no Änderungen an der Lambda-generierten API-Schicht vorgenommen.

Hier ist mein NodeJS:

'use strict';
const doc = require('dynamodb-doc');
const dynamo = new doc.DynamoDB();
exports.handler = ( event, context, callback ) => {
    const done = ( err, res ) => callback( null, {
        statusCode: err ? '400' : '200',
        body: err ? err.message : JSON.stringify(res),
        headers:{ 'Access-Control-Allow-Origin' : '*' },
    });
    switch( event.httpMethod ) {
        ...
    }
};

Hier ist mein AJAX Aufruf

$.ajax({
    url: 'https://x.execute-api.x-x-x.amazonaws.com/prod/fnXx?TableName=x',
    type: 'GET',
    beforeSend: function(){ $( '#loader' ).show();},
    success: function( res ) { alert( JSON.stringify(res) ); },
    error:function(e){ alert('Lambda returned error\n\n' + e.responseText); },
    complete:function(){ $('#loader').hide(); }
});
9
MannyC

1) Ich musste das gleiche wie @riseres und einige andere Änderungen machen. Das sind meine Antwort-Header:

headers: {
            'Access-Control-Allow-Origin' : '*',
            'Access-Control-Allow-Headers':'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token',
            'Access-Control-Allow-Credentials' : true,
            'Content-Type': 'application/json'
        }

2 und

Laut dieser Dokumentation:

http://docs.aws.Amazon.com/apigateway/latest/developerguide/how-to-cors.html

Wenn Sie einen Proxy für Lambda-Funktionen in der API Gateway-Konfiguration verwenden, haben die Post- oder Get-Methoden keine hinzugefügten Header, nur die Optionen. Sie müssen dies manuell in der Antwort (Server- oder Lambda-Antwort) tun.

3) und

Außerdem musste ich die Option "API Key Required" in meiner API-Gateway-Post-Methode deaktivieren.

Wenn Sie alles in Bezug auf dieses Problem ohne Erfolg versucht haben, landen Sie dort, wo ich es getan habe. Es stellt sich heraus, dass die bestehenden Anweisungen für das CORS-Setup bei Amazon einwandfrei funktionieren. Vergessen Sie nicht, erneut bereitzustellen . Der CORS-Bearbeitungsassistent aktualisiert Ihre API trotz aller kleinen grünen Häkchen nicht live. Vielleicht offensichtlich, aber es hat mich einen halben Tag lang überrascht.

enter image description here

2
lase

In meinem Fall habe ich die Abrufanforderungs-URL einfach falsch geschrieben. In serverless.yml setzen Sie cors auf true:

register-downloadable-client:
    handler: fetch-downloadable-client-data/register.register
    events:
      - http:
          path: register-downloadable-client
          method: post
          integration: lambda
          cors: true
          stage: ${self:custom.stage}

und dann über den Lambda-Handler senden Sie die Header, aber wenn Sie die Abrufanforderung im Frontend falsch machen, erhalten Sie diesen Header nicht für die Antwort und Sie erhalten diesen Fehler. Überprüfen Sie also Ihre Anforderungs-URL auf der Vorderseite.

0

Ich bekam meine Arbeit, als mir klar wurde, dass der Lambda-Autorisierer ausfiel und aus unbekannten Gründen in einen CORS-Fehler übersetzt wurde. Ein einfacher Fix für meinen Autor (und einige Autorentests, die ich eigentlich hätte hinzufügen sollen) und es hat funktioniert. Für mich war die API-Gateway-Aktion "Enable CORS" erforderlich. Dies fügte alle Header und andere Einstellungen hinzu, die ich in meiner API benötigte.

0
RodP

Da ich in meinem Fall AWS_IAM als Autorisierungsmethode verwendet habe, musste ich meinen IAM-Rollen Berechtigungen erteilen, um den Endpunkt zu erreichen.

0
CamHart

Ich verwende aws-serverless-express und musste in meinem Fall simple-proxy-api.yaml bearbeiten. 

Bevor CORS für https://example.com konfiguriert wurde, habe ich nur den Namen meiner Site getauscht und über npm run setup neu bereitgestellt. Außerdem wurde mein vorhandener Lambda/Stack aktualisiert.

#...
/:
#...
method.response.header.Access-Control-Allow-Origin: "'https://example.com'"
#...
/{proxy+}:
method.response.header.Access-Control-Allow-Origin: "'https://example.com'"
#...
0
James L.

Eine weitere Ursache für dieses Problem könnte ein Unterschied zwischen HTTP/1.1 und HTTP/2 sein.

Symptom: Einige Benutzer, nicht alle von ihnen, haben bei der Verwendung unserer Software einen CORS-Fehler gemeldet.

Problem: Der Access-Control-Allow-Origin -Header fehlte manchmal .

Kontext: Wir hatten ein Lambda eingerichtet, das sich der Behandlung von OPTIONS-Anfragen und der Beantwortung der entsprechenden CORS-Header widmete, z. B. Access-Control-Allow-Origin, der mit einer Whitelist Origin übereinstimmt.

Lösung: Das API-Gateway scheint alle Header für HTTP/2-Aufrufe in Kleinbuchstaben umzuwandeln, behält jedoch die Großschreibung für HTTP/1.1 bei. Dies führte dazu, dass der Zugriff auf event.headers.Origin fehlschlug.

Überprüfen Sie, ob Sie dieses Problem auch haben:

Angenommen, Ihre API befindet sich unter https://api.example.com und Ihr Front-End unter https://www.example.com. Stellen Sie mit CURL eine Anfrage über HTTP/2:

curl -v -X OPTIONS -H 'Origin: https://www.example.com' https://api.example.com

Die Antwortausgabe sollte den Header enthalten:

< Access-Control-Allow-Origin: https://www.example.com

Wiederholen Sie denselben Schritt mit HTTP/1.1 (oder mit einem Origin-Header in Kleinbuchstaben):

curl -v -X OPTIONS --http1.1 -H 'Origin: https://www.example.com' https://api.example.com

Wenn der Header Access-Control-Allow-Origin fehlt, möchten Sie möglicherweise die Groß- und Kleinschreibung prüfen, wenn Sie den Header Origin lesen.

0
Michael Seibt