api - habilitar - no ''access-control-allow-origin'' header is present on the requested resource.

AWS API Gateway-CORS+POST no funciona

Question

CORS realmente me está volviendo loco y realmente no tengo ideas sobre qué hacer para que funcione.

Creé APIG APi simple con 1 recurso llamado ''abc'' y agregué 2 métodos GET y POST ambos con Authorization establecido en NONE y API Key Required establecido en falso , todo implementado en una etapa llamada ''dev''.

Por supuesto habilité CORS en ambos métodos y veo los 3 encabezados Access-Control-Allow-Origin , Access-Control-Allow-Headers y Access-Control-Allow-Methods añadidos al método OPTIONS y Access-Control-Allow- Origen agregado a los métodos POST y GET .

Ambas llamadas se asignan a la misma función lambda que simplemente genera un texto de "Hola desde Lambda" a la consola.

Luego creé una página html simple que alojé como sitio web estático en S3 , le señalé un dominio usando Route53 y comencé a probar la API usando jQuery $ .ajax para hacer las llamadas.

Todo parece fácil, directo y exactamente como se explica en los documentos, excepto que solo GET funciona y envía el texto a la consola como se esperaba. La versión POST produce el siguiente error:

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.

La llamada de verificación previa funciona y devuelve 200 OK y todos los encabezados están allí, pero la llamada POST devuelve ese error y una solicitud incorrecta de 400.

Por favor, cualquier ayuda es realmente apreciada, espero que el equipo de AWS también esté mirando ...

Gracias chicos.

EDITADO - Copiado de Google Chrome:

POST encabezados de solicitud en bruto:

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 encabezados de respuesta en bruto:

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==

Esto devuelve 400 Bad Request

OPCIONES Encabezados de solicitud en bruto:

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

OPCIONES Raw Response Headers:

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

Esto devuelve 200 OK

Answer 1

Bien, encontré el origen del problema, que no tiene ninguna relación con APIG, y confirma lo que @AbhignaNagaraja mencionó, que mi APIG se configuró correctamente.

El problema está en la forma en que llamé jQuery.ajax, que pensé que era lo suficientemente inteligente como para convertir mis parámetros en una cadena JSON cuando contentType es ''application / json''. Parece que tuve que codificar manualmente los parámetros JSON en lugar de pasar un JSON y tener jQuery stringify it.

Entonces esta es la mala llamada:

$.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);
}
});

Y esta es la llamada correcta:

 $.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);
}
});

Esto puede ser una pista si está depurando un problema de este tipo con CORS: simplemente descargue AWS APIG SDK e intente ejecutar la llamada utilizando el apigClient provisto por AWS y compare los encabezados con los que obtiene con su cliente personalizado. Al examinar los 2 conjuntos de encabezados que obtuve con jQuery y apigClient , noté que la carga de solicitud se veía diferente y así es como me di cuenta de que el formato era incorrecto, entonces el código 400 y el encabezado No ''Access-Control-Allow-Origin'' están presentes todo tiene sentido.

Espero que esto ayude.

Answer 2

Tuve un problema similar, pero con la integración del proxy lambda:

• CORS activado en AWS API Gateway utilizando el navegador

• integración lambda-proxy activada

Al usar la integración del proxy lambda, puede devolver encabezados personalizados desde dentro del código de la lambda:

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

De esta forma, obtienes el encabezado CORS enviado. Creo que podría haber una forma mejor de hacerlo funcionar con la integración del proxy lambda sin acoplar el CORS dentro del código de la lambda, por favor, avíseme si lo sabe.

Answer 3

Tuve un problema similar, y no tenía nada que ver con la forma en que se configuró la API ni con la solicitud POST que estaba haciendo en el front-end. Lo que me solucionó el problema fue implementar la API en AWS API Gateway. Una vez que crea un método / recurso de API y los vincula a una función lambda, no se implementan automáticamente.

Debe hacer clic en "Acciones" y luego en "Implementar API" para acceder a estos MicroServicios desde el front-end.