API Gateway CORS : 'Access-Control-Allow-Origin'헤더 없음

CORS가 API Gateway를 통해 설정되고 Access-Control-Allow-Origin헤더가 설정되었지만 Chrome 내 AJAX에서 API를 호출하려고하면 여전히 다음 오류가 발생합니다.

XMLHttpRequest는 http://XXXXX.execute-api.us-west-2.amazonaws.com/beta/YYYYY를 로드 할 수 없습니다 . 요청 된 리소스에 'Access-Control-Allow-Origin'헤더가 없습니다. 따라서 Origin 'null'은 액세스가 허용되지 않습니다. 응답에 HTTP 상태 코드 403이 있습니다.

Postman을 통해 URL을 얻으 려고 시도했는데 위의 헤더가 성공적으로 전달되었음을 보여줍니다.

그리고 OPTIONS 응답에서 :

JSON-P로 되 돌리지 않고 브라우저에서 API를 호출하려면 어떻게해야합니까?

나는 같은 문제가 발생합니다. 나는 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-Gateway는 사용자 지정 권한 부 여자에서 4xx를 반환 할 때 CORS에 대해 구성되지 않습니다.

또한 -API Gateway를 통해 실행되는 요청에서 상태 코드를 0받거나 1받는 경우 이는 아마도 문제 일 수 있습니다.

수정하려면-API Gateway 구성에서- "Gateway Responses"로 이동하여 "Default 4XX"를 확장하고 거기에 CORS 구성 헤더를 추가합니다. 즉

Access-Control-Allow-Origin: '*'

게이트웨이를 다시 배포해야합니다 .

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 키 필요'옵션을 비활성화해야했습니다.

이 문제에 관한 모든 것을 시도해도 소용이 없다면 내가 한 곳으로 끝날 것입니다. Amazon의 기존 CORS 설정 지침은 정상적으로 작동합니다. 재배포하는 것을 잊지 마십시오 ! CORS 편집 마법사는 작은 녹색 확인 표시가 모두 있어도 API를 실시간으로 업데이트하지 않습니다. 당연한 것 같지만 반나절 동안 나를 괴롭혔다.

샘플 작동 : 방금 생성 된 nodejs Lambda 함수의 headers : {} 안에 'Access-Control-Allow-Origin': '*'를 삽입했습니다 . 나는하지 아니 람다 생성 된 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(); }
});

Google 직원 :

그 이유는 다음과 같습니다.

• 간단한 요청 또는 GET/ POST쿠키가없는 경우 프리 플라이트를 트리거하지 않습니다.
• 경로에 대한 CORS를 구성하면 API Gateway는 OPTIONS해당 경로에 대한 메서드 만 생성 한 다음 Allow-Origin사용자가 호출 할 때 모의 응답을 사용하여 헤더 를 전송 OPTIONS하지만 GET/ POST는 Allow-Origin자동으로 가져 오지 않습니다.
• CORS 모드가 켜진 상태에서 간단한 요청을 보내려고하면 해당 응답에 Allow-Origin헤더 가 없기 때문에 오류가 발생합니다.
• 모범 사례를 준수 할 수 있습니다. 단순 요청은 사용자에게 응답을 보내는 것이 아니라 인증 / 쿠키를 "간단하지 않은"요청과 함께 전송하고 프리 플라이트가 트리거됩니다.
• 그래도 다음 요청에 대해 CORS 헤더를 직접 보내야합니다. OPTIONS

그것을 요 ​​약하기:

• OPTIONSAPI Gateway에 의해 무해한 것만 자동으로 생성됩니다.
• OPTIONS브라우저 에서 경로에서 CORS 가능성 을 확인하기위한 신중한 조치로만 사용됩니다.
• CORS 허용 여부 는 실제 방법 (예 : GET/POST
• 응답에 적절한 헤더를 수동으로 보내야합니다.

방금 람다 함수 응답에 헤더를 추가했는데 매력처럼 작동했습니다.

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

내에서 간단한 해결책을 찾았습니다.

API Gateway> API 엔드 포인트 선택> 방법 선택 (제 경우에는 POST)

이제 드롭 다운 작업> CORS 활성화 .. 선택하십시오.

이제 드롭 다운 작업을 다시 선택> API 배포 (다시 배포)

작동했습니다!

람다 작성자가 실패하고 CORS 오류로 변환되는 알 수없는 이유로 인해 작업을 수행했습니다. 내 작성자에 대한 간단한 수정 (그리고 처음에 추가해야하는 일부 작성자 테스트)이 작동했습니다. 나를 위해 API 게이트웨이 작업 'CORS 활성화'가 필요했습니다. 이것은 API에 필요한 모든 헤더 및 기타 설정을 추가했습니다.

저에게있어서 최종적으로 작업 한 답변은 Alex R의 답변 (두 번째로 많은 찬성)에서 James Shapiro의 댓글이었습니다. 처음에는 S3에서 호스팅되는 정적 웹 페이지를 가져 와서 람다를 사용하여 연락처 페이지를 처리하고 이메일을 보내려고 시도함으로써이 API 게이트웨이 문제에 직면했습니다. [] 기본값 4XX를 선택하기 만하면 오류 메시지가 수정되었습니다.

기능 또는 코드를 변경 한 후 다음 두 단계를 따르십시오.

먼저 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'"
#...

제 경우에는 API Gateway에 대한 권한 부여 방법으로 AWS_IAM을 사용하고 있었기 때문에 엔드 포인트에 도달 할 수있는 IAM 역할 권한을 부여해야했습니다.

이 문제의 또 다른 근본 원인은 HTTP / 1.1과 HTTP / 2의 차이 일 수 있습니다.

증상 : 모두가 아닌 일부 사용자가 소프트웨어를 사용할 때 CORS 오류가 발생한다고보고했습니다.

문제 :Access-Control-Allow-Origin 헤더가 누락 된 가끔 .

컨텍스트 :OPTIONS 요청 을 처리 하고 해당 CORS 헤더로 응답하는 데 전념하는 Lambda가 준비되어 있습니다 (예 : Access-Control-Allow-Originwhitelisted Origin.

솔루션 : API Gateway는 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)가있는 경우 헤더를 직접 추가해야합니다.

제 경우에는 단순히 가져 오기 요청 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
    })
 }