web-dev-qa-db-ja.com

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を取得しようとしましたが、上記のヘッダーが正常に渡されたことを示しています。

Passed headers

そして、OPTIONSの回答から:

Response headers

JSON-Pに戻らずにブラウザーからAPIを呼び出すにはどうすればよいですか?

61
Tyler

同じ問題が発生します。私は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);
};
76
riseres

まだ他の誰かがこれに直面している場合-私は私のアプリケーションの根本原因を追跡することができました。

カスタムオーソライザーでAPI-Gatewayを実行している場合-API-Gatewayは、実際にサーバーにヒットする前に401または403を送り返します。デフォルトでは、カスタム認証から4xxを返す場合、API-GatewayはCORS用に構成されていません。

また、API Gatewayを介して実行されているリクエストから0または1のステータスコードを取得している場合、これはおそらく問題です。

修正するには、API Gateway構成で「Gateway Responses」に進み、「Default 4XX」を展開して、そこにCORS構成ヘッダーを追加します。つまり.

Access-Control-Allow-Origin: '*'

ゲートウェイを再デプロイするようにしてください-そして出来上がり!

61
Gabriel Doty

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

このドキュメントによると:

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

API Gateway構成でラムダ関数のプロキシを使用する場合、postまたはgetメソッドにはヘッダーが追加されず、オプションのみが追加されます。応答(サーバーまたはラムダ応答)で手動で行う必要があります。

3)And

それに加えて、APIゲートウェイのpostメソッドで「API Key Required」オプションを無効にする必要がありました。

サンプルが動作するようになりました:I just Inserted 'Access-Control-Allow-Origin': '*'、 inside headers:{}生成されたnodejs Lambda関数。 Lambdaで生成されたAPIレイヤーをnoに変更しました。

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(); }
});
10
MannyC

ラムダオーソライザーが失敗していること、そして何らかの未知の理由でCORSエラーに変換されていることに気付いた後、私は私の仕事を得ました。私のオーソライザー(および最初に追加する必要のあるオーソライザーのテスト)の簡単な修正とそれが機能しました。私にとっては、API Gatewayアクション「Enable CORS」が必要でした。これにより、APIに必要なすべてのヘッダーとその他の設定が追加されました。

3
RodP

この問題に関するすべてを試してみた場合、結局私がやったことになるでしょう。結局のところ、Amazonの既存のCORSセットアップの指示はうまく機能します...再配置することを忘れないでください! CORS編集ウィザードは、素敵な小さな緑色のチェックマークがすべて付いていても、APIのライブ更新を行いません。おそらく明らかですが、それは私を半日困惑させました。

enter image description here

2
lase

私の場合、フェッチリクエストURLを間違って記述していました。 serverless.ymlで、corstrueに設定しました:

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を前面で再確認してください。

0

私の場合、承認メソッドとしてAWS_IAMを使用していたため、エンドポイントにアクセスするためにIAMロールのアクセス許可を付与する必要がありました。

0
CamHart

私は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'"
#...
0
James L.

この問題の別の根本的な原因は、HTTP/1.1とHTTP/2の違いです。

症状:すべてのユーザーではなく一部のユーザーが、ソフトウェアの使用時にCORSエラーが発生することが報告されました。

問題:Access-Control-Allow-Originヘッダーが欠落していましたsometimes

コンテキスト:OPTIONSリクエストを処理し、Access-Control-Allow-Originがホワイトリストに登録されたOriginと一致するなど、対応するCORSヘッダーで応答するための専用のLambdaがありました。

解決策: 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ヘッダーを読み取るときに大文字と小文字の区別を確認することをお勧めします。

0
Michael Seibt