提案された コード は常に下に近かった：

config/initializers/cors.rb

Rails.application.config.middleware.insert_before 0, Rack::Cors do
許可する
オリジン ''
リソース '', ヘッダ: :any, メソッド: :any
end
end

そして残念なことに、これらのテキストはプロダクションで実際に何をすべきかをほとんど説明してくれなかった。

コピーペーストはかなりOKです(私はときどき冗談で、企業はStack Overflowのコピー・パスターを雇うことができるのではないかと思うことがある。)、「コピー」と「ペースト」の間に「考えて調整する」瞬間がある限り。そこで、ここでやっていること、そしてそれが実際にどのように機能するのか、少し詳しく説明したいと思う。

オナー理論の簡単な紹介から始めて、Railsの例題に移っても構わないだろうか。

はじめに

最初から始めよう。説明しやすくするために、序章を3つのパートに分けた。最初のパートでは、原点とは何か、つまりここで議論していることの重要な用語について概説します。2つ目はSOPについての簡単な説明です。そして最後のパートは CORS そのものだ。

原点とは何か？

MDN Web Docsによると

- ウェブコンテンツのオリジンは、アクセスに使われるURLのスキーム（プロトコル）、ホスト（ドメイン）、ポートによって定義される。2つのオブジェクトが同じオリジンを持つのは、スキーム、ホスト、ポートがすべて一致する場合だけです (ソース)

それはかなり明確なようですね？念のため、MDNから2つの例を分析してみよう。

1. http://example.com/app1/index.html, http://example.com/app2/index.html

上の2つは同じ起源だからだ：

• 彼らのスキーム（http）は同じだ、
• ドメイン（example.com）は同じです、
• 両者のポート（暗黙の）は同じである。

2. http://www.example.com, http://myapp.example.com

この2つは、ドメイン(www.example.com, myapp.example.com)は異なる。

十分理解できたと思う。そうでない場合は、MDN Web Docsでより多くの例をご覧ください。

SOPとは何か？

MDN Web Docsによると(ソース):

- 同一オリジン・ポリシーは、あるオリジンからロードされたドキュメントやスクリプトが、他のオリジンのリソースとどのように相互作用するかを制限する重要なセキュリティ・メカニズムです。潜在的に悪意のあるドキュメントを隔離し、攻撃ベクトルを減らすのに役立ちます。

- クロスオリジンの書き込みは通常許可されています。例としては、リンク、リダイレクト、フォーム送信などがあります。

- 通常、クロスオリジン埋め込みは許可されている。

- クロスオリジンリードは通常禁止されているが、埋め込みによってリードアクセスが漏れることはよくある。
用途 CORS クロスオリジンアクセスを許可する

まあ、おわかりのように、SOPの定義にはオリジンを超えた行動に関するものが多い。それでもいい。私たちが今知っておくべきことは、同じオリジンにはより多くの権限があり、CORSを使うことでクロスオリジンのルールを緩めることができるということだ。そして、ここで次のセクションが登場する。

CORSとは？

MDNの言葉に基づいている：

• クロスオリジンリソース共有(CORS)は、HTTPヘッダーに基づくメカニズムで、ブラウザがリソースの読み込みを許可すべき、サーバー自身のオリジン以外のオリジン(ドメイン、スキーム、ポート)を示すことができます。CORSはまた、ブラウザがクロスオリジンリソースをホストするサーバーに「プリフライト」リクエストを行い、サーバーが実際のリクエストを許可するかどうかをチェックするメカニズムに依存しています。このプリフライトでは、ブラウザは実際のリクエストで使用されるHTTPメソッドとヘッダーを示すヘッダーを送信します。 (ソース).

それでもまだ十分ではない。そこで明言されなかったのは、以下のヘッダーを使用する際に最も重要なことだ。 CORS は アクセス制御-許可-オリジン:

• について アクセス制御-許可-オリジン レスポンスヘッダは、指定されたオリジン(ソース).

まあ、これで終わりだろう。実生活では CORS通常、次のように設定します。 ACAO ヘッダーが先だ。

実生活

定義については以上です。Railsと実例に戻りましょう。

RailsでCORSを設定するには？

私たちは（言われたように）間違いなくラックコールを使う。最初のスニペット（他の記事で最も多く提供されているもの）を思い出してみよう：

config/initializers/cors.rb

Rails.application.config.middleware.insert_before 0, Rack::Cors do
許可する
オリジン ''
リソース '', ヘッダ: :any, メソッド: :any
end
end

選択肢は膨大、いや無限だが、この2つを考えてみよう：

• 私たちは、サードパーティのブラウザ・クライアントが使用できるAPIを構築している、
• 典型的なフロントエンドとバックエンドの分離で、信頼できるクライアントがAPIにアクセスできるようにしたい。

サードパーティクライアントからアクセスされるAPIの構築

最初の選択肢に直面した場合、おそらく次のようになるだろう。 出自 他の人があなたのAPIの上にクライアントを構築することを望んでいて、その人が誰なのか知らないんでしょう？

典型的なフロントエンドとバックエンドの分離

もしあなたが後者を開発しているのであれば、APIへのクロスオリジン・リクエストを皆にさせたくないはずだ。むしろそうしたいはずだ：

• 本番クライアントが本番APIにアクセスできるようにする、
• ステージングも同じだ、
• localhostも同じです、
• FEレビューアプリがステージングにアクセスできるようにしたい。

言われたように）ラックコールを使うことに変わりはない。

ENV変数を2つ使ってみよう： 許可されたオリジン リテラルなオリジン定義（アスタリスクまたは実際のURL）には allowed_origin_regexps パターンのために。

config/initializers/cors.rb

frozenstringliteral: true

toregexp = ->(string) { Regexp.new(string) }.
hosts = [
*ENV.fetch('ALLOWEDORIGINS').split(',')、
*ENV.fetch('ALLOWEDORIGINREGEXPS').split(';').map(&to_regexp)
]

Rails.application.config.middleware.insert_before 0, Rack::Cors do
許可する
オリジン(*hosts)

リソース '*'、
         methods: %i[get post put patch delete options head]、
         ヘッダ: :any

終了
エンド

何が起こっているんだ？

1. 見ての通り、ENV変数で定義された値を異なるセパレーターで分割している。これは、セミコロンがURL定義パターンに現れる可能性が低いからだ。
2. リテラル値はすぐに使えるが、パターンを実際のRegexpインスタンスにマッピングしなければならない。
3. そして、これらのホストが、APIが使用するホワイトリストに登録されたメソッドを持つリソースにアクセスできるようにする。

これにより、開発環境、ステージング環境、本番環境で適切な値を定義するのに十分な柔軟性が得られるはずだ。

結論

以上、要点をまとめてみよう：

• ENV変数を使用して設定する CORS,
• 正規表現を使用して、異なるオリジンからのステージングAPIへのアクセスを許可する（レビューアプリの場合など）、
• "コピー "と "ペースト "の間には、常に "考えて調整 "を入れる。

以上です。良い一日を 🙂。

続きを読む

なぜ（おそらく）Typescriptを使うべきなのか？

2021年に注目すべきニューヨークのスタートアップ10社