API Gateway CORS：「Access-Control-Allow-Origin」ヘッダーなし

CORSはAPIGatewayを介して設定され、Access-Control-Allow-Originヘッダーが設定されていますが、Chrome内でAJAXからAPIを呼び出そうとすると、次のエラーが発生します。

XMLHttpRequestはhttp://XXXXX.execute-api.us-west-2.amazonaws.com/beta/YYYYYを読み込めません。要求されたリソースに「Access-Control-Allow-Origin」ヘッダーがありません。したがって、オリジン 'null'はアクセスを許可されません。応答のHTTPステータスコードは403でした。

Postmanを介してURLを取得しようとしましたが、上記のヘッダーが正常に渡されたことが示されています。

そして、オプションの応答から：

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を送り返します。デフォルト-カスタムオーソライザーから4xxを返す場合、API-GatewayはCORS用に構成されていません。

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

修正するには（APIゲートウェイ構成で）「ゲートウェイ応答」に移動し、「デフォルト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ゲートウェイのpostメソッドで「APIKeyRequired」オプションを無効にする必要がありました。

この問題に関するすべてを無駄に試した場合、私が行った場所に行き着くでしょう。結局のところ、Amazonの既存のCORSセットアップ手順は問題なく機能します...再デプロイすることを忘れないでください！CORS編集ウィザードは、小さな緑色のチェックマークがすべて付いていても、APIをライブで更新しません。おそらく明白ですが、それは私を半日困惑させました。

私は：私のサンプルの作業手に入れただけで挿入された「アクセス制御-許可-起源」：「*」、内側の{}：ヘッダをラムダ関数nodejs生成に。Lambdaで生成された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/ POSTCookieなしではプリフライトはトリガーされません
• パスにCORSを設定すると、API GatewayはOPTIONSそのパスのメソッドのみを作成し、Allow-Originユーザーが呼び出したときに模擬応答を使用してヘッダーを送信しますがOPTIONS、GET/POSTはAllow-Origin自動的に取得されません
• CORSモードをオンにして単純なリクエストを送信しようとすると、その応答にAllow-Originヘッダーがないため、エラーが発生します
• ベストプラクティスに従うことができます。単純なリクエストはユーザーに応答を送信することを意図したものではなく、リクエストと一緒に認証/ Cookieを送信して「シンプルではない」ようにし、プリフライトがトリガーされます
• それでも、次のリクエストでは、CORSヘッダーを自分で送信する必要があります OPTIONS

要約すると：

• 無害なものだけがAPIGatewayOPTIONSによって自動的に生成されます
• 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ゲートウェイ> APIエンドポイントを選択>メソッドを選択（私の場合はPOSTでした）

ドロップダウンアクション> CORSを有効にする..それを選択します。

次に、ドロップダウンアクションを再度選択します> APIをデプロイします（再デプロイします）

出来た ！

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

私にとって、最終的に機能した答えは、Alex Rの答え（2番目に賛成）からのJamesShapiroからのコメントでした。そもそも、S3でホストされている静的Webページを取得して、ラムダを使用して連絡先ページを処理し、電子メールを送信しようとして、このAPIGatewayの問題に直面しました。[]デフォルトの4XXをチェックするだけで、エラーメッセージが修正されました。

関数またはコードを変更した後次の2つの手順に従います。

最初にCORSを有効にし、次に毎回APIをデプロイします。

両方POSTでCORSを有効にした後でコードをデプロイし、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ロール権限を付与する必要がありました。

この問題のもう1つの根本的な原因は、HTTP /1.1とHTTP / 2の違いである可能性があります。

症状：すべてではない一部のユーザーが、ソフトウェアの使用時にCORSエラーを受け取ると報告しました。

問題：Access-Control-Allow-Originヘッダが欠落していました、時々。

コンテキスト：ホワイトリストへの照合OPTIONSなど、リクエストの処理と対応するCORSヘッダーでの返信専用のLambdaを配置しました。Access-Control-Allow-OriginOrigin

解決策： 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ヘッダーが返されるかどうかです。

'Enable CORS'を実行すると、200ステータスしか設定されません。エンドポイントに他のユーザー（4xxや5xxなど）がある場合は、ヘッダーを自分で追加する必要があります。