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 Gateway構成で、「Gateway Responses」に移動し、「Default 4XX」を展開して、そこにCORS構成ヘッダーを追加します。すなわち
Access-Control-Allow-Origin: '*'
ゲートウェイを再デプロイしてください-そして出来上がり！
aws apigateway update-gateway-response --rest-api-id "XXXXXXXXX" --response-type "DEFAULT_4XX" --patch-operations op="add",path="/responseParameters/gatewayresponse.header.Access-Control-Allow-Origin",value='"'"'*'"'"'
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なしではプリフライトはトリガーされませんOPTIONSそのパスのメソッドのみを作成し、Allow-Originユーザーが呼び出したときにモック応答を使用してヘッダーを送信しますがOPTIONS、GET/POSTはAllow-Origin自動的に取得されませんAllow-Originヘッダーがないため、エラーが発生しますOPTIONS要約すると：
OPTIONSによって自動的に生成されますOPTIONSパス上の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をデプロイします（再デプロイします）
出来た ！
私にとって、最終的に機能した答えは、Alex Rの答え（2番目に賛成）からのJamesShapiroからのコメントでした。そもそも、S3でホストされている静的ウェブページを取得してラムダを使用してcontact-usページを処理し、メールを送信しようとして、この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'"
#...
この問題のもう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など）がある場合は、ヘッダーを自分で追加する必要があります。
私の場合、フェッチリクエストの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
})
}
Bucket Policyか？ポリシーにメソッドがあることを確認してください