クロスドメインの問題と nginx が 403 ACAO を処理する方法

1. クロスドメインとは何ですか? クロスドメインソリューション

ブラウザの同一オリジンポリシー制限のため。同一生成元ポリシー (同一生成元ポリシー) は、ブラウザの中核かつ最も基本的なセキュリティ機能である規約であり、同一生成元ポリシーが存在しない場合、ブラウザの通常の機能に影響を与える可能性があります。Web は同一オリジンポリシーに基づいて構築されており、ブラウザは同一オリジンポリシーの実装にすぎないと言えます。同一生成元ポリシーは、あるドメインの JavaScript スクリプトが別のドメインのコンテンツと対話することを防ぎます。いわゆる同じオリジン (つまり、同じドメイン内) とは、2 つのページが同じプロトコル (protocol)、ホスト (host)、およびポート番号 (port) を持ち、現在のページの URL が異なる、つまりクロスを意味します
。 -ドメイン

次の表は、クロスドメインの種類を視覚的に表示するために使用されます。

現在のページの URL	リクエストされたページの URL	クロスドメインかどうか	理由
http://www.test.com/	http://www.test.com/index.html	いいえ	同じオリジン（同じプロトコル、ドメイン名、ポート番号）
http://www.test.com/	https://www.test.com/index.html	クロスドメイン	プロトコルが異なります（http/https）
http://www.test.com/	http://www.baidu.com/	クロスドメイン	メインドメイン名が異なります（test/baidu）
http://www.test.com/	http://blog.test.com/	クロスドメイン	異なるサブドメイン (www/blog)
http://www.test.com:8080/	http://www.test.com:7001/	クロスドメイン	異なるポート番号 (8080/7001)

2. 故障状況

403 クロスドメインエラーが発生すると、要求されたリソースに「Access-Control-Allow-Origin」ヘッダーが存在しません。Nginx サーバーの応答ヘッダーパラメーターを構成する必要があります: Nginx の処理方法、Nginx 構成の
変更

        location / {
    
       
        proxy_pass  http://127.0.0.1:8010;
        add_header 'Access-Control-Allow-Origin' '*';
	    add_header 'Access-Control-Allow-Credentials' 'true';
     	add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
	    add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
	    add_header Content-Security-Policy "upgrade-insecure-requests;connect-src *";

            }

3. 構成の詳細

Access-Control-Allow-Origin
サーバーは、デフォルトではドメインを越えることができません。Nginx サーバーを構成するとAccess-Control-Allow-Origin *、サーバーはすべてのリクエストソース (Origin)、つまりすべてのクロスドメインリクエストを受け入れることができることになります。
Access-Control-Allow-Headers は、次のエラーを防ぐためのものです。
Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

このエラーは、現在のリクエスト Content-Type の値がサポートされていないことを示します。実際、これは「application/json」というタイプのリクエストを開始したことが原因でした。ここには、プリフライトリクエスト (プリフライトリクエスト) という概念が関係しています。以下の「プリフライトリクエスト」の概要を参照してください。

Access-Control-Allow-Methods は、次のエラーを防ぐためのものです。
Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

4. POST リクエストを送信するときに Nginx が依然としてアクセスを拒否するというエラーに対処するために、OPTIONS に 204 リターンを追加します。
「プリフライトリクエスト」(以下で紹介) を送信するときは、メソッド OPTIONS を使用する必要があるため、サーバーが許可する必要があります。この方法。

5. すべての HTTP リクエストを強制的に HTTPS リクエストに置き換えます

4. プリフライトリクエスト

実際、上記の構成には、クロスオリジン要求を解決するために提案された W3C 標準である CROS が含まれています。正式名はクロスオリジンリソース共有 (Cross-Origin Resource Sharing) です。

Cross-Origin Resource Sharing (CORS) 標準では、サーバーがどのオリジンサイトにどのリソースへのアクセス許可があるかを宣言できるようにする HTTP ヘッダーフィールドの新しいセットが追加されています。さらに、仕様では、サーバーデータに副作用をもたらす可能性がある HTTP リクエストメソッド (特に GET 以外の HTTP リクエスト、または特定の MIME タイプを使用した POST リクエスト) について、ブラウザは最初に OPTIONS メソッドを使用してプリフライトリクエストを開始する必要があります。（プリフライトリクエスト）サーバーがクロスドメインリクエストを許可しているかどうかを知るため。サーバーが許可を確認した後、実際の HTTP リクエストが開始されます。プリフライト要求を返す際、サーバーは、アイデンティティ資格情報 (Cookie および HTTP 認証関連データを含む) を伝送するかどうかをクライアントに通知することもできます。
実際、Content-Type フィールドが application/json であるリクエストは、特定の MIME タイプを持つ上記の POST リクエストですが、CORS では、次の MIME タイプに属さない Content-Type はすべて事前チェックリクエストであると規定されています。

application/x-www-form-urlencoded
multipart/form-data
text/plain

したがって、アプリケーション/json リクエストは正式な通信の前に「事前チェック」リクエストを追加し、この「事前チェック」リクエストはヘッダー情報をもたらします。

Access-Control-Request-Headers: Content-Type：

OPTIONS /api/test HTTP/1.1
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type

…一部省略
サーバーが応答したときに、返されたヘッダー情報に Access-Control-Allow-Headers: Content-Type が含まれていない場合は、デフォルト以外の Content-Type が受け入れられないことを意味します。つまり、次のエラーが発生します。

Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

記事の内容の一部は
https://segmentfault.com/a/1190000012550346
https://blog.csdn.net/qq_38128179/article/details/84956552から転送されています。