Rack::CorsでCORSの設定

SinatraやRailsでCORSの設定をする時に、よくRack::Corsを利用します。
その時の設定と注意点を。

SinatraでRack::Corsを使う

SinatraでRack::Corsを使う時は、READMEに書かれている通りです。

www.khasegawa.netからのリクエストを許可する

例として、このサイト(www.khasegawa.net)からのリクエストを許可するようにしてみます。
originsにwww.khasegawa.netと単一で指定するだけですね。



これでリクエストが通るようになりました。
この時のAccess-Control-Allow--Originは、https://www.khasegawa.netになり、期待する値になっていることも確認出来ますね。

他のドメインからも許可する

他のドメイン(example.com)からもリクエストを許可します。
originsメソッドの引数は、可変長引数となっているため、example.comを追加します。



これでリクエストが通るようになりました。
簡単ですね。

この時のAccess-Control-Allow--Originは、「www.khasegawa.net」からリクエストした場合、https://www.khasegawa.netになり、「example.com」からのリクエストの場合は、https://example.comという期待する値になっていることも確認出来ます。

複数指定した場合は、マッチしたホストが設定されています。(正確にはschemeやポートを含めてものだが)

www.khasegawa.netとsub.khasegawa.netを許可する

Rack::Corsでは、引数に正規表現を指定することも出来るので、それを利用します。



正規表現で指定する場合の注意点としては、セキュリティを考慮し、schemeを含めた完全一致にすることをオススメします。

この時のAccess-Control-Allow--Originは、「www.khasegawa.net」からリクエストした場合、https://www.khasegawa.netになり、「sub.khasegawa.com」からのリクエストの場合は、https://sub.khasegawa.comという期待する値になっていることも確認出来ますね。

正規表現を指定した場合は、マッチしたホストを返却するようになっています。

挙動から分かる注意点

これらから分かることはなんでしょうか。
どれだけ指定しても、Access-Control-Allow-Originに設定される値は、1つなのです。(許可されていない場合は何も設定されない)
ということは、どこかでレスポンスをキャッシュすると不都合が出そうです。

これは、READMEのCommon Gotchasに書いてあることからも分かります。
Common GotchasのCachingでは、Rack::Cacheの話しか出ていませんが、要はキャッシュさせないでっていうことですね。

こういうのは、見落としがちだったりするので要注意ですね。

コメント

このブログの人気の投稿

新生活始まります

ElasticIPを複数利用する時の注意

タスクの実行結果をwhenで指定するならcheck_modeつける