背景
API Gateway＋Lambda(Python)で、HTML上のフォームで情報をPOST送信すると、バックエンドで処理をするサービスを作りました。
しかし、CORS周りを正しく構成しているはずなのに、何度POSTしてもエラーが・・・
そんなときの備忘録です。
エラーメッセージ
Access to XMLHttpRequest at ‘https://XXX.execute-api.ap-northeast-1.amazonaws.com/prd/upload_to_s3‘ from origin ‘https://XXX‘ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
状況
CORSを理解していませんが、とりあえずWebの情報で色々対処しても、なおエラーが起きる状況でした
LambdaではCORS関連のヘッダを返すようにしています。これがないと、ブラウザ上でエラーになるようです。
API GatewayはCORS関連の設定済みです。OPTIONSが自動追加されました（プロキシ結合を使っています）
エラーログの確認方法
当時、私はブラウザ上の開発者モードのコンソールしか、エラーログを確認するすべを知りませんでした。。
しかし、様々な実行ログは、AWS上ではCloudWatch Logsに集約されるそうです。。
CloudWatchにアクセスし、ログ→ロググループを見ると、/aws/lambda/upload_to_s3という今回CORSエラーが起きていそうなLambda関数のログが出ていそうでした。
（逆に、最初は気づかなかったので、いつか「知らない間に料金が発生！」となっていた可能性も・・・）
こちらを見ると、HTML上からAPI GatewayにPOSTした内容は、Lambdaには届いてそうでした（時刻から判断）
内容を見てみると、Lambda（Python）で何やらエラーが起きていそうでした。
入力データにb_flagという列がほしいところ、存在していないため処理が止まっているようでした。
つまり、Python側で想定外だったときの処理が考慮漏れしており、想定外だった時、returnされるものが無いので、
CORSヘッダも付かず、ブラウザでは内容を見る前にCORSヘッダがないのでエラーが出ていた…ということになります。
起きていたこと・やっておくべきだったこと
「CORSエラー」と出ていますが、Lambda上のPythonの実装で考慮漏れが悪さしていました。。
ブラウザでしか確認していなかった私が悪いです。はい。
以下をやっておけば、もっとすぐ気づけたかもしれません
- Lambda単体テストをちゃんとやる（プロキシ結合だと面倒くさい・・・）
- Pythonで途中エラーが起きたときも、処理を止めず何かしらreturnする（ただしエラーメッセージを誰にでも表示するのはセキュリティ上よろしくない側面もあります）
- API Gateway側でも何かしらログを取る？仕組みを作っておく（ただし、Lambdaだけ取れていれば十分かもしれません）