AWS API Gateway - CORS + POST nie działa

Question

CORS naprawdę doprowadza mnie do szaleństwa i nie mam pomysłów na to, co powinienem spróbować.

Stworzyłem prostą APIG Api z 1 zasobu o nazwie 'abc' i dodaje się 2 metody GET i POST zarówno z Autoryzacja zestaw do BRAK i API Key Wymagane zestaw do fałszywego , wszystko wdrożone na etapie zwanym "dev".

Oczywiście Po włączeniu kor obu metod i widzę 3 złącza pinowe kontroli dostępu pozwalaj pochodzenia, kontroli dostępu-ce-Główki i Access Control Pozwala-Metody dodano do OPCJI Sposób i Access-Control-Allow-Origin dodany do POST i GET metod.

Obie rozmowy są odwzorowywane na tę samą funkcję lambda, która po prostu wyświetla tekst "Witaj z lambda" na konsoli.

Potem stworzyliśmy prostą stronę HTML Prowadziłem jako statycznej stronie na S3, wskazał domenę do niego używając Route53 i rozpoczęliśmy testy API przy użyciu jQuery $ .ajax dokonać połączenia .

Wszystko wydaje się proste, proste i dokładnie takie, jak wyjaśniono w dokumentach, z wyjątkiem tego, że tylko GET działa i wysyła tekst do konsoli zgodnie z oczekiwaniami. W POST Wyniki wersji w następujący błąd:

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://example.com' is therefore not allowed access. The response had HTTP status code 400.

Do inspekcji wstępnych prac połączeń i zwraca 200 OK i wszystkie nagłówki istnieją, ale wywołanie POST zwraca ten błąd i 400 Bad Request.

Proszę każda pomoc jest bardzo ceniona, mam nadzieję, że ekipa AWS ogląda zbyt ...

Dzięki chłopaki.

---

EDYCJI - Skopiowane z Google Chrome:

POST Surowce Nagłówki żądań:

POST /dev/urls HTTP/1.1 
Host: kykul1mshe.execute-api.us-east-1.amazonaws.com 
Connection: keep-alive 
Content-Length: 73 
Accept: application/json, text/javascript, */*; q=0.01 
Origin: http://example.com 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 
Content-Type: application/json 
Referer: http://example.com/dev.html 
Accept-Encoding: gzip, deflate, br 
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4 

POST Surowce Response Nagłówki:

HTTP/1.1 400 Bad Request 
Date: Fri, 19 Aug 2016 02:14:16 GMT 
Content-Type: application/json 
Content-Length: 177 
Connection: keep-alive 
x-amzn-RequestId: a1160e45-65b2-11e6-9766-cd61e49fbcdb 
X-Cache: Error from cloudfront 
Via: 1.1 d64756b4df47ce24d6c62b5a8de97e87.cloudfront.net (CloudFront) 
X-Amz-Cf-Id: N9mf7apicKbSM_MiZjePbEgZGIFKckWJ3lZljH8iHVKFVTcIIOQuHg== 

ta zwraca 400 Bad Request

OPCJE Raw Zapytaj Nagłówki:

Accept:*/* 
Accept-Encoding:gzip, deflate, sdch, br 
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4 
Access-Control-Request-Headers:accept, content-type 
Access-Control-Request-Method:POST 
Connection:keep-alive 
Host:kykul1mshe.execute-api.us-east-1.amazonaws.com 
Origin:http://example.com 
Referer:http://example.com/dev.html 
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 

OPCJE Raw Response Nagłówki:

Access-Control-Allow-Headers:Content-Type,X-Amz-Date,Authorization,X-Api-Key,Cache-Control,X-Requested-With 
Access-Control-Allow-Methods:POST,OPTIONS 
Access-Control-Allow-Origin:* 
Connection:keep-alive 
Content-Length:79 
Content-Type:application/json 
Date:Fri, 19 Aug 2016 02:14:16 GMT 
Via:1.1 d64756b4df47ce24d6c62b5a8de97e87.cloudfront.net (CloudFront) 
X-Amz-Cf-Id:KpGEDmIuf5RHcUnBWuA3oEMZgWHwrjy3SpLuOflRhAD8IIx5vyKGSw== 
x-amzn-RequestId:a10bae11-65b2-11e6-bcf7-63b49c24629e 
X-Cache:Miss from cloudfront 

ta zwraca 200 OK

Answer 1

Ok, znalazłem źródło problemu, co zdarza się być całkowicie niezwiązane z APIG i potwierdza, o czym wspomniała @AbhignaNagaraja, że ​​mój APIG został poprawnie skonfigurowany.

Problem jest rzeczywiście w drodze zadzwoniłem jQuery.ajax, co uważałem, że było wystarczająco inteligentny, aby przekształcić swoje parametry na ciąg JSON gdy contentType jest „application/json”. Wydaje się, że musiałem ręcznie uszeregować parametry JSON zamiast przekazywać JSON i mieć jQuery stringify go.

Więc to jest złe wezwanie:

$.ajax({ 
     url: myEndpoint, 
     type: 'POST', 
     crossDomain: true, 
     data: { 
      url: $('#url').val() 
     }, 
     headers: { 
      "X-Api-Key": 'blablabla' 
     }, 
     dataType: 'json', 
     contentType: "application/json", 
     success: function (data) { 
      console.info(data); 
     } 
    }); 

I to jest właściwe powołanie:

$.ajax({ 
     url: myEndpoint, 
     type: 'POST', 
     crossDomain: true, 
     data: JSON.stringify({ 
      url: $('#url').val() 
     }), 
     headers: { 
      "X-Api-Key": 'blablabla' 
     }, 
     dataType: 'json', 
     contentType: "application/json", 
     success: function (data) { 
      console.info(data); 
     } 
    }); 

To może być wskazówka, jeśli debugowanie taki problem z CORS: wystarczy pobrać AWS APIG SDK i spróbuj wykonać połączenie za pomocą apigClient dostarczonego przez AWS i porównaj nagłówki z tymi, które otrzymasz z niestandardowym klientem. Badając 2 zestawy nagłówków dostałem z jQuery i apigClient zauważyłem Request Ładunek wyglądał inaczej i to w jaki sposób realizowany format mylił, to 400 Kod a nie „kontroli dostępu -Allow-Origin ' nagłówek jest obecny ma sens.

Mam nadzieję, że to pomoże.

Answer 2

Miałem podobny problem - i nie miało to nic wspólnego ze sposobem, w jaki API zostało skonfigurowane, ani z żądaniem POST, które robiłem na front-endie. Rozwiązałem problem polegający na wdrożeniu interfejsu API w AWS API Gateway. Po utworzeniu metody/zasobu interfejsu API i powiązaniu ich z funkcją lambda nie są one automatycznie wdrażane.

Musisz kliknąć "Akcje", a następnie "Wdróż API", aby uzyskać dostęp do tych MicroServices z front-end.

Answer 3

Miałem podobny problem, ale z lambda integracji Proxy:

• Cors aktywowane na AWS API bramy przy użyciu przeglądarki

• integracja lambda-proxy aktywowany

Kiedy korzystając z integracji z serwerem lambda, możesz zwrócić niestandardowe nagłówki z wnętrza kodu lambda:

 var result = { 
     statusCode: data.statusCode | 200, 
     headers: { 
      "Access-Control-Allow-Origin": "*" 
     }, 
     body: JSON.stringify(responseBody) 
    }; 
    callback(null, result); 

W ten sposób otrzymasz nagłówek CORS. Myślę, że może istnieć lepszy sposób na to, aby działał z integracją lambda bez sprzężenia CORS z kodem lambda, proszę dać mi znać, jeśli wiesz.

Answer 4

Było wiele postów, które kierują tobą, aby upewnić się, że funkcja lambda zwraca odpowiednie nagłówki CORS, i są one poprawne. Jest jednak również krytyczne, że obiekt Json jest stringified przy użyciu JSON.stringify(). Wygląda na to, że Postman robi to za nas, więc jest to mylące, gdy żądanie listonosza i żądanie $ .ajax wysyła ten sam obiekt Json; jednak się to udaje i jeden się nie udaje.