CORS
忘れたらここを読むだけで思い出せる
ブラウザがリクエストを送るか判断するための情報をサーバーからAccess-Control-Allow-xxxヘッダーとして返す
ブラウザは単純リクエストじゃない場合に事前にOPTIONリクエストをサーバーに送って本番リクエストを送っても良いか判断する
概要
cross origin resource sharing
オリジン間リソース共有
オリジン→HTMLを読み込んだサーバー
ブラウザが通信を制御する枠組みなのでcurlとかバックエンド同士の通信には影響しない
ブラウザにはクロスドメイン通信を拒否するように実装されている。これはクロスサイトスクリプトを防ぐため
hiroki.iconサーバーが誰のリソースなのかを認識することが大切だね。ユーザーはhtmlを獲得している元を意識しているわけでそれ以外の第三者への通信は基本的に意図しない訳だし
https://dev.classmethod.jp/articles/cors-cross-origin-resource-sharing-cross-domain/
この記事古い
なんとなく CORS がわかる...はもう終わりにする。
https://gyazo.com/c9f723b95f514c4b9450b46f0d597015
Same-Origin Policy
ポリシー
オリジン間のリソース共有を許さない
XSS
CSRF
を防げる
プリフライトリクエスト
https://qiita.com/nnishimura/items/1f156f05b26a5bce3672
https://future-architect.github.io/articles/20200717/
ブラウザからサーバーへhttpリクエストを送る前にOPTIONSリクエストを送信する動作のこと
本番リクエストの前のテストリクエストのようなイメージ
ブラウザ固有の動作でありcurlとかでリクエスト飛ばす時にはない
httpリクエストが単純リクエストとみなされればプリフライトリクエスト(OPTION)は飛ばない
その他
S3とCORS
バケットに対してCORSの設定が出来る
エラー時の心構え
CORS エラーに遭遇した時は冷静にリクエストの流れを辿り、どのサーバーで CORS の許可設定がされていないのかを確認するようにしましょう。エラー内容から読み解くことができるはずです。