API Gateway CORS: нет заголовка Access-Control-Allow-Origin

У меня такая же проблема. Я использовал 10 часов, чтобы узнать.

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

Если кто-то еще сталкивается с этим, я смог отследить основную причину в моем приложении.

Если вы используете API-Gateway с настраиваемыми авторизаторами, API-Gateway отправит 401 или 403 обратно, прежде чем он действительно попадет на ваш сервер. По умолчанию - API-шлюз НЕ настроен для CORS при возврате 4xx из настраиваемого авторизатора.

Также - если вы получаете код состояния 0 или 1 из запроса, проходящего через API Gateway, вероятно, это ваша проблема.

Чтобы исправить - в конфигурации шлюза API - перейдите в «Ответы шлюза», разверните «По умолчанию 4XX» и добавьте туда заголовок конфигурации CORS. т.е.

Access-Control-Allow-Origin: '*'

Не забудьте повторно развернуть шлюз - и вуаля!

Если вы попробовали все, что касалось этой проблемы, безрезультатно, вы окажетесь там же, где и я. Оказывается, существующие в Amazon инструкции по настройке CORS работают нормально ... просто убедитесь, что вы не забыли выполнить повторное развертывание! Мастер редактирования CORS, даже со всеми его красивыми маленькими зелеными галочками, не обновляет ваш API в реальном времени. Возможно, очевидно, но это озадачило меня на полдня.

1) Мне нужно было сделать то же самое, что и @riseres, и некоторые другие изменения. Это мои заголовки ответов:

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

Согласно этой документации:

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

Когда вы используете прокси для лямбда-функций в конфигурации API Gateway, методы post или get не имеют добавленных заголовков, только параметры. Вы должны сделать это вручную в ответе (ответ сервера или лямбда-ответа).

3) И

Кроме того, мне нужно было отключить параметр «Требуется ключ API» в моем методе публикации шлюза API.

Мой образец заработал: я только вставил 'Access-Control-Allow-Origin': '*', внутри заголовков: {} в сгенерированная функция nodejs лямбда. Я не внес никаких изменений в слой API, созданный лямбда-выражением.

Вот мой 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 ) {
        ...
    }
};

Вот мой вызов 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(); }
});

Я просто добавил заголовки в свой ответ лямбда-функции, и он работал как шарм

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

Для сотрудников Google:

Вот почему:

• Простой запрос или _1 _ / _ 2_ без файлов cookie не запускает предпечатную проверку
• Когда вы настраиваете CORS для пути, API Gateway создает только OPTIONS метод для этого пути, а затем отправляет Allow-Origin заголовки, используя фиктивные ответы, когда пользователь вызывает OPTIONS, но GET / POST не получит Allow-Origin автоматически.
• Если вы попытаетесь отправить простые запросы с включенным режимом CORS, вы получите сообщение об ошибке, потому что этот ответ не имеет заголовка Allow-Origin.
• Вы можете придерживаться передовой практики, простые запросы не предназначены для отправки ответа пользователю, отправьте аутентификацию / файл cookie вместе с вашими запросами, чтобы сделать его «непростым», и предварительная проверка запустит
• Тем не менее, вам придется самостоятельно отправлять заголовки CORS для запроса, следующего за OPTIONS

Подвести итог:

• Только безобидные OPTIONS будут сгенерированы API Gateway автоматически
• OPTIONS используются браузером только в качестве меры предосторожности для проверки возможности CORS на пути
• Принятие CORS зависит от фактического метода, например. GET / POST
• Вы должны вручную отправить соответствующие заголовки в своем ответе.

Для меня ответ, который НАКОНЕЦ Сработал, был комментарием Джеймса Шапиро из ответа Alex R (второй по количеству голосов). Я столкнулся с этой проблемой API-шлюза в первую очередь, пытаясь получить статическую веб-страницу, размещенную в S3, для использования лямбда-выражения для обработки страницы контактов и отправки электронного письма. Простая проверка [] Default 4XX исправила сообщение об ошибке.

Я нашел простое решение в

API Gateway> Выберите конечную точку API> Выберите метод (в моем случае это был POST)

Теперь есть выпадающий список ДЕЙСТВИЯ> Включить CORS .. выберите его.

Теперь снова выберите раскрывающийся список ДЕЙСТВИЯ> Развернуть API (повторно развернуть)

Это сработало !

Я начал свою работу после того, как понял, что авторизатор лямбда не работает и по какой-то неизвестной причине это переводится в ошибку CORS. Простое исправление для моего авторизатора (и некоторые тесты авторизатора, которые я должен был добавить в первую очередь), и это сработало. Для меня требовалось действие шлюза API «Включить CORS». Это добавило все заголовки и другие настройки, которые мне нужны в моем API.

После изменения функции или кода Выполните следующие два шага.

Сначала включайте CORS, затем каждый раз развертывайте API.

Развертывание кода после включения CORS для POST и OPTIONS сработало для меня.

Я использую aws-serverless-express, и в моем случае нужно отредактировать simple-proxy-api.yaml.

До того, как CORS был настроен на https://example.com, я просто заменил имя своего сайта и повторно развернул его через npm run setup, и он обновил мой существующий лямбда / стек.

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

В моем случае, поскольку я использовал AWS_IAM в качестве метода авторизации для шлюза API, мне нужно было предоставить разрешения моей роли IAM для попадания в конечную точку.

Для меня, поскольку я использовал довольно стандартные вызовы React fetch, это можно было исправить с помощью некоторых из исправлений AWS Console и Lambda, описанных выше, но моя Lambda вернула правильные заголовки (я также использовал режим прокси), и мне нужно было упаковать мои приложение в шаблон SAM, поэтому я не мог тратить время, щелкая по консоли.

Я заметил, что все элементы CORS работали нормально, ПОКА я не поставил Cognito Auth в свое приложение. Я просто очень медленно выполнял развертывание пакета SAM / SAM со все большим количеством конфигураций, пока он не сломался, и он не сломался, как только я добавил Auth в свой API-шлюз. Я провел целый день, просматривая замечательные дискуссии, подобные этой, в поисках простого решения, но в конце концов мне пришлось прочитать о том, что делает CORS. Я сохраню вам чтение и дам вам еще одно легкое решение (по крайней мере, для меня).

Вот пример окончательно сработавшего шаблона шлюза API (YAML):

Resources:
  MySearchApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: 'Dev'
      Cors:
        AllowMethods: "'OPTIONS, GET'"
        AllowHeaders: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token'"
        AllowOrigin: "'*'"
      Auth:
        DefaultAuthorizer: MyCognitoSearchAuth
        Authorizers:
          MyCognitoSearchAuth:
            UserPoolArn: "<my hardcoded user pool ARN>"
            AuthType: "COGNITO_USER_POOLS"
        AddDefaultAuthorizerToCorsPreflight: False

Обратите внимание на AddDefaultAuthorizerToCorsPreflight внизу. По умолчанию это True, если у вас НЕТ в вашем шаблоне, насколько я могу судить из моего чтения. И, когда True, он как бы блокирует нормальное поведение OPTIONS, чтобы объявить, что ресурс поддерживает с точки зрения разрешенного происхождения. Как только я явно добавил его и установил значение False, все мои проблемы были решены.

Подразумевается, что если у вас возникла эта проблема и вы хотите диагностировать ее более полно, вам следует посетить свои ресурсы в API-шлюзе и проверить, содержит ли ваш метод OPTIONS какую-либо форму аутентификации. Вашему GET или POST требуется Auth, но если в ваших OPTIONS включен Auth, вы можете оказаться в этой ситуации. Если вы щелкаете по консоли AWS, попробуйте удалить из OPTIONS, повторно развернуть, а затем протестировать. Если вы используете SAM CLI, попробуйте мое исправление, указанное выше.

Убедитесь, что вы звоните по правильному пути.

Попадание по несуществующему пути может вызвать ошибки, связанные с CORS, по любой причине. Вероятно, из-за того, что 404 не включает заголовки CORS в свой ответ.

Благодаря комментарию @ jackko к первоначальному вопросу. Это была моя проблема. Звучит глупо, но может случиться с кем угодно.

Другой основной причиной этой проблемы может быть разница между HTTP / 1.1 и HTTP / 2.

Симптом. Некоторые пользователи, не все из них, сообщали об ошибке CORS при использовании нашего Программного обеспечения.

Проблема: заголовок Access-Control-Allow-Origin отсутствовал иногда.

Контекст. У нас есть лямбда-выражение, предназначенное для обработки OPTIONS запросов и ответов с соответствующими заголовками CORS, например Access-Control-Allow-Origin, совпадающими с Origin из белого списка.

Решение. Похоже, что шлюз API переводит все заголовки в нижний регистр для вызовов HTTP / 2, но сохраняет заглавные буквы для HTTP / 1.1. Это привело к сбою доступа к event.headers.origin.

Проверьте, не возникает ли у вас тоже эта проблема:

Предположим, что ваш API расположен по адресу https://api.example.com, а ваш интерфейс - по адресу https://www.example.com. Используя CURL, сделайте запрос по HTTP / 2:

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

Выходные данные ответа должны включать заголовок:

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

Повторите тот же шаг, используя HTTP / 1.1 (или с заголовком Origin в нижнем регистре):

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

Если заголовок Access-Control-Allow-Origin отсутствует, вы можете проверить чувствительность к регистру при чтении заголовка Origin.

Помимо других комментариев, стоит обратить внимание на статус, возвращаемый вашей базовой интеграцией, и если для этого статуса возвращается заголовок Access-Control-Allow-Origin.

Выполнение функции «Включить CORS» устанавливает только статус 200. Если у вас есть другие на конечной точке, например 4xx и 5xx, вам нужно добавить заголовок самостоятельно.

В моем случае я включил все методы и ответы шлюза. Тогда это сработало как шарм. Не забудьте развернуть.

Тем, кто использует авторизаторы Cognito в API Gateway, на самом деле нет необходимости устанавливать собственные ответы шлюза. API Gateway блокирует предполетный запуск, потому что они не авторизованы по умолчанию логикой AWS.

К счастью, есть встроенный параметр, чтобы исправить это. Просто добавьте AddDefaultAuthorizerToCorsPreflight: False в свой API Authorizer, и API Gateway отключит аутентификацию для предполетных запросов. Вот документация и пример настройки:

MyApi:
Type: AWS::Serverless::Api
Properties:
  StageName: Prod
  Cors: 
    AllowHeaders: "'*'"
    AllowMethods: "'*'"
    AllowOrigin: "'*'"
  Auth:
    DefaultAuthorizer: MyCognitoAuthorizer
    AddDefaultAuthorizerToCorsPreflight: False
    Authorizers:
      MyCognitoAuthorizer:
        UserPoolArn: !GetAtt MyCognitoUserPool.Arn

В моем случае я просто неправильно написал URL-адрес запроса на выборку. На serverless.yml вы устанавливаете cors на 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}

а затем в обработчике лямбда вы отправляете заголовки, но если вы сделаете запрос на выборку неправильно во внешнем интерфейсе, вы не получите этот заголовок в ответе, и вы получите эту ошибку. Итак, дважды проверьте URL-адрес вашего запроса на передней панели.

В Python вы можете сделать это, как показано в коде ниже:

{ "statusCode" : 200,
'headers': 
    {'Content-Type': 'application/json',
    'Access-Control-Allow-Origin': "*"
     },
"body": json.dumps(
    {
    "temperature" : tempArray,
    "time": timeArray
    })
 }