API Gateway CORS: sin encabezado 'Access-Control-Allow-Origin'

Aunque CORS se ha configurado a través de API Gateway y el Access-Control-Allow-Originencabezado está configurado, sigo recibiendo el siguiente error cuando intento llamar a la API desde AJAX dentro de Chrome:

XMLHttpRequest no puede cargar http://XXXXX.execute-api.us-west-2.amazonaws.com/beta/YYYYY . No hay un encabezado 'Access-Control-Allow-Origin' presente en el recurso solicitado. Por lo tanto, no se permite el acceso al origen 'nulo'. La respuesta tenía el código de estado HTTP 403.

Intenté OBTENER la URL a través de Postman y muestra que el encabezado anterior se pasó correctamente:

Y de la respuesta de OPCIONES:

¿Cómo puedo llamar a mi API desde el navegador sin volver a JSON-P?

Tengo el mismo problema. He utilizado 10 horas para averiguarlo.

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

Si alguien más se encuentra con esto todavía, pude rastrear la causa raíz en mi aplicación.

Si está ejecutando API-Gateway con autorizadores personalizados, API-Gateway enviará un 401 o 403 antes de que llegue a su servidor. De forma predeterminada, API-Gateway NO está configurado para CORS cuando se devuelve 4xx desde un autorizador personalizado.

También - si quieres pasar a estar recibiendo un código de estado 0o 1de una petición que corre a través de la API de puerta de enlace, esto es probablemente su problema.

Para solucionarlo, en la configuración de API Gateway, vaya a "Respuestas de puerta de enlace", expanda "4XX predeterminado" y agregue un encabezado de configuración CORS allí. es decir

Access-Control-Allow-Origin: '*'

Asegúrese de volver a implementar su puerta de enlace , ¡y listo!

1) Necesitaba hacer lo mismo que @riseres y algunos otros cambios. Estos son mis encabezados de respuesta:

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) Y

Según esta documentación:

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

Cuando usa proxy para funciones lambda en la configuración de API Gateway, los métodos post u get no tienen encabezados agregados, solo las opciones. Debe hacerlo manualmente en la respuesta (servidor o respuesta lambda).

3) Y

Además de eso, necesitaba deshabilitar la opción 'Se requiere clave API' en mi método de publicación de puerta de enlace API.

Si ha intentado todo lo relacionado con este tema sin éxito, terminará donde lo hice. Resulta que las instrucciones de configuración de CORS existentes de Amazon funcionan bien ... ¡solo asegúrese de recordar volver a implementar ! El asistente de edición CORS, incluso con todas sus pequeñas y agradables marcas de verificación verdes, no realiza actualizaciones en vivo de su API. Quizás obvio, pero me dejó perplejo durante medio día.

Hice funcionar mi muestra: acabo de insertar 'Access-Control-Allow-Origin': '*', dentro de los encabezados: {} en la función Lambda de nodejs generada. Hice no hay cambios en la capa API generada-Lambda.

Aquí está mi 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 ) {
        ...
    }
};

Aquí está mi llamada AJAX

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

Para los empleados de Google:

He aquí por qué:

• Solicitud simple, o GET/ POSTsin cookies no activa la verificación previa
• Cuando configura CORS para una ruta, API Gateway solo creará un OPTIONSmétodo para esa ruta, luego enviará Allow-Originencabezados usando respuestas simuladas cuando el usuario llame OPTIONS, pero GET/ POSTno obtendrá Allow-Originautomáticamente
• Si intenta enviar solicitudes simples con el modo CORS activado, obtendrá un error porque esa respuesta no tiene Allow-Originencabezado
• Puede adherirse a las mejores prácticas, las solicitudes simples no están destinadas a enviar una respuesta al usuario, enviar autenticación / cookie junto con sus solicitudes para que sea "no simple" y se activará la verificación previa.
• Aún así, tendrá que enviar los encabezados CORS usted mismo para la siguiente solicitud OPTIONS

Para resumirlo:

• OPTIONSAPI Gateway solo generará inofensivo
• OPTIONSsolo son utilizados por el navegador como medida de precaución para verificar la posibilidad de CORS en una ruta
• La aceptación de CORS dependerá del método real, p GET. Ej .POST
• Tienes que enviar manualmente los encabezados apropiados en tu respuesta

Acabo de agregar encabezados a la respuesta de mi función lambda y funcionó como un encanto

exports.handler = async (event) => {
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hey it works'),
        headers:{ 'Access-Control-Allow-Origin' : '*' }
    };
    return response;
};

Encontré una solución simple dentro

API Gateway> Seleccione su punto final de API> Seleccione el método (en mi caso fue el POST)

Ahora hay un menú desplegable ACCIONES> Habilitar CORS ... selecciónelo.

Ahora seleccione el menú desplegable ACCIONES nuevamente> Implementar API (volver a implementarlo)

Funcionó !

Hice que el mío funcionara después de darme cuenta de que el autorizador lambda estaba fallando y, por alguna razón desconocida, se estaba traduciendo en un error CORS. Una solución simple para mi autorizador (y algunas pruebas de autorizador que debería haber agregado en primer lugar) y funcionó. Para mí, se requería la acción de API Gateway 'Habilitar CORS'. Esto agregó todos los encabezados y otras configuraciones que necesitaba en mi API.

Para mí, la respuesta que FINALMENTE FUNCIONÓ, fue el comentario de James Shapiro de la respuesta de Alex R (la segunda más votada). En primer lugar, me metí en este problema de API Gateway, al intentar obtener una página web estática alojada en S3 para usar lambda para procesar la página de contacto y enviar un correo electrónico. Simplemente marcando [] Default 4XX solucionó el mensaje de error.

Después de cambiar su función o código, siga estos dos pasos.

Primero habilite CORS y luego implemente API cada vez.

Implementar el código después de habilitar CORS para ambos POSTy OPTIONSfuncionó para mí.

Estoy corriendo aws-serverless-express, y en mi caso necesitaba editar simple-proxy-api.yaml.

Antes de que se configurara CORS https://example.com, simplemente cambié el nombre de mi sitio y lo volví a implementar a través de npm run setup, y actualicé mi lambda / pila existente.

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

En mi caso, dado que estaba usando AWS_IAM como el método de autorización para API Gateway, necesitaba otorgar mis permisos de rol de IAM para llegar al punto final.

Otra causa raíz de este problema podría ser una diferencia entre HTTP / 1.1 y HTTP / 2.

Síntoma: algunos usuarios, no todos, informaron que obtenían un error CORS al usar nuestro software.

Problema: La Access-Control-Allow-Origincabecera faltaba veces .

Contexto: teníamos una Lambda en su lugar, dedicada a manejar OPTIONSsolicitudes y responder con los encabezados CORS correspondientes, como hacer Access-Control-Allow-Origincoincidir una lista blanca Origin.

Solución: API Gateway parece transformar todos los encabezados a minúsculas para las llamadas HTTP / 2, pero mantiene las mayúsculas para HTTP / 1.1. Esto provocó event.headers.originque fallara el acceso a .

Compruebe si también tiene este problema:

Suponiendo que su API está ubicada en https://api.example.com, y su interfaz está en https://www.example.com. Usando CURL, haga una solicitud usando HTTP / 2:

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

La salida de respuesta debe incluir el encabezado:

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

Repita el mismo paso usando HTTP / 1.1 (o con un Originencabezado en minúsculas ):

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

Si Access-Control-Allow-Originfalta el encabezado, es posible que desee verificar la distinción entre mayúsculas y minúsculas al leer el Originencabezado.

Además de otros comentarios, algo a tener en cuenta es el estado devuelto por su integración subyacente y si se devuelve el encabezado Access-Control-Allow-Origin para ese estado.

Hacer lo 'Habilitar CORS' solo configura el estado 200. Si tiene otros en el punto final, por ejemplo, 4xx y 5xx, debe agregar el encabezado usted mismo.