web-dev-qa-db-ja.com

原点マッチングを使用してCORSを有効にするためのnginx config

CORSを使用すると、正規表現を使用して原点マッチングをサポートするNGINXの場合は、 非常に人気のある設定 を使用しようとしました。

これが私の設定です:

server {
    listen 80 default_server;
    root /var/www;

    location / {
        if ($http_Origin ~ '^http://(www\.)?example.com$') {
            add_header Access-Control-Allow-Origin "$http_Origin";
        }

        # Handling preflight requests
        if ($request_method = OPTIONS) {
            add_header Content-Type text/plain;
            add_header Content-Length 0;
            return 204;
        }
    }
}
 _

ただし、この設定は2つの条件を使用する必要があります。オリジンドメイン名と別のものと一致するものとプリフライト要求をキャプチャするために使用する必要があります。そのため、2番目の条件が一致すると、最初の条件からのヘッダーは応答に追加されません。

悪があれば オフィシャル記事では、これはNGINXの予想される動作です。

もしも If Is Evil nginxでCorsを有効にする方法それとも、どういうわけかこの制限を克服する方法があるかもしれませんか?

4
Slava Fomin II

解決策のみ これまでのところ、複数の条件を集計してからそれを単一のIFステートメントのみと一致させるためのハッキングです。したがって、いくつかのディレクティブを複製します。

server {
    listen 80 default_server;
    root /var/www;

    location / {
        set $cors '';
        set $cors_allowed_methods 'OPTIONS, HEAD, GET';

        if ($http_Origin ~ '^https?://(www\.)?example.com$') {
            set $cors 'Origin_matched';
        }

        # Preflight requests
        if ($request_method = OPTIONS) {
            set $cors '${cors} & preflight';
        }

        if ($cors = 'Origin_matched') {
            add_header Access-Control-Allow-Origin $http_Origin;
        }

        if ($cors = 'Origin_matched & preflight') {
            add_header Access-Control-Allow-Origin $http_Origin always;
            add_header Access-Control-Allow-Methods $cors_allowed_methods;
            add_header Content-Type text/plain;
            add_header Content-Length 0;
            return 204;
        }
    }
}
 _
2
Slava Fomin II