Mopidy: 静的ファイルアセットのCORS応答ヘッダーがありません

残念ながら、 Access-Control-Allow-Originヘッダーは単一の値しか許可しません。 構成済みリストから複数の値をサポートする場合は、少し注意が必要です。

可能なAccess-Control-Allow-Origin値を許可されたオリジンのセットに制限するには、サーバー側でOriginリクエストヘッダーの値を確認し、許可されたオリジンのリストと比較して、Originの値がリスト。Access-Control-Allow-Originの値をOriginの値と同じ値に設定します。

さらに悪いことに、私が理解しているように、CORSリクエストでない限り、Originリクエストヘッダーであることに依存することはできません。 また、HTTPSリクエストがない場合のRefererヘッダー（使用する代替ヘッダー）があることに依存することもできません。 これが、すべてがプリフライトCORSダンスを実行することを保証する非常に複雑なCSRF保護コードにつながった理由です（注：これはその後変更され、すべてのブラウザーPOSTがOriginヘッダーを取得するようになりましたか？）。 ここでそれが欲しいのは間違いない。

StaticFileHandlerは「安全な」GETリクエストのみを処理するため、応答ヘッダー「Access-Control-Allow-Origin：*」を設定するだけで問題ないのではないでしょうか。

これについてもっと考えてみると（望んでいないにもかかわらず）、CORSポリシーの維持に関係するブラウザーはすべてOriginヘッダーを送信していると言っても過言ではありません。 したがって、設定されているOriginヘッダーに基づいて条件付きでcheck_origin()を実行し、許可されている場合は、通常のようにヘッダー値をAccess-Control-Allow-Origin応答ヘッダーにコピーできます。 Originヘッダーがない場合、動作は変更できません。

これについてもっと考える（したくないにもかかわらず）

ごめんなさい。 ：see_no_evil：

さて、静的アセットの何が特別なのですか？ すでに存在するすべてのクールなロジックを再利用できないのはなぜですか。 私が間違っていなければ、オリジンヘッダーなどのppのすべてのチェックがすでにそこにあることを意味します。 条件付きでヘッダーを設定して利用することはできませんか？ ：考え：

そのGETリクエストとCORSポリシーだけが、POSTのような副作用のある「安全でない」メソッドのCRSF保護と同じではありません。 それらは異なる問題であり、解決策はまったく同じではありません。

しかし、そのほとんどを再利用することはできます。それが、2番目のメッセージで私が言おうとしていたことです。

私の最後のメッセージは意味がありましたか？ 修正を実装したいですか、それともやるべきことのリストに追加しますか？

はい、それは理にかなっています。 ：スマイリー：

あなたがそれをリストに加えることができればクールだろう。 コードを調べて何が欠けているのかを理解することはできましたが、ここで使用されるフレームワークと何を処理する必要があるかについての知識が少なすぎます。 ごめん。 ：see_no_evil：

これはかなり孤立した修正だと思いますが、はい、トルネードを確認する必要があるので、報告してくれてありがとう。