Nginxリバースプロキシを使用してクロスドメインの問題を解決する

クロスドメインの問題

クロスドメインとは、リクエストがサーバーに到達したが、戻ってきたときにブラウザによって制限されていることを意味します。Pythonがデータを取得できるのと同じように、ブラウザを経由せずにデータを取得してリクエストを開始できます。クロスドメインの問題を解決するには、Nginxのリバースプロキシを使用することを考えています。

プロキシサーバー

プロキシサーバー。クライアントがリクエストを送信すると、宛先ホストに直接送信するのではなく、最初にプロキシサーバーに送信します。プロキシサービスがクライアントリクエストを受け入れた後、ホストに送信し、データを受信します。宛先ホストから返され、プロキシに保存されます。サーバーのハードディスクで、クライアントに送信します。

フォワードプロキシ

ユーザーはターゲットサーバーのアドレスを知っていますが、ネットワークの制限やその他の理由により、ターゲットサーバーに直接アクセスすることはできません。このとき、最初にプロキシサーバーに接続する必要があります。そうすれば、プロキシサーバーはターゲットサーバーにアクセスできます。たとえば、Googleにアクセスできませんが、海外にvpsがあり、Googleにアクセスできます。アクセスし、Googleへのアクセスを要求した後、データを送信します。

リバースプロキシ

いわゆるリバースプロキシは、フォワードプロキシの正反対であり、プロキシサーバーはターゲットサーバーにサービスを提供しますが、全体的な要求の戻りルートは、クライアントからプロキシ、サーバーへと同じです。
たとえば、BaiduのWebサイトにアクセスすると、Baiduのプロキシサーバーの外部ドメイン名はhttps://www.baidu.comになります。特定の内部サーバーノードはわかりません。実際には、Baiduのプロキシサーバーにアクセスした後、プロキシサーバーはN個のサーバーノードの1つにリクエストを転送して、検索して結果を返します。

別の例：お金も必要ですが、誰がお金を持っているのかわからないため、オンライン貸付プラットフォームを見つけました。情報を送信すると、オンライン貸付プラットフォームから直接送金されます。しかし、オンライン貸付プラットフォームからお金がどこから来るのかわからないので、注意を払う必要はありません。裕福な所有者が資金を調達できるオンライン貸付プラットフォーム。あなたにとって、オンラインローンプラットフォームとその資金提供者は同じです。

また、上記の例から、プロキシサーバーと背後のターゲットホストがシステム（Baidu社、オンラインローンプラットフォーム）であることがわかります。彼らは外の世界にサービスを提供するので、彼らはリバースエージェントと呼ばれ、彼らは背後にいる人々です。

Nginxリバースプロキシ構成

403クロスドメインエラーが発生し、要求されたリソースに「Access-Control-Allow-Origin」ヘッダーが存在しない場合、Nginxサーバーの応答ヘッダーパラメーターを構成する必要があります

add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers X-Requested-With;
add_header Access-Control-Allow-Methods GET,POST,OPTIONS;

Nginxで次のパラメーターを構成します。

location / {
    
      
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
    add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';

    if ($request_method = 'OPTIONS') {
    
    
        return 204;
    }
} 

説明

1.Access-Control-Allow-Origin

サーバーは、デフォルトではドメイン間を移動できません。Nginxサーバーを構成Access-Control-Allow-Origin *すると、サーバーはすべてのリクエストソース（オリジン）を受け入れることができます。つまり、すべてのクロスドメインリクエストを受け入れることができます。

2. Access-Control-Allow-Headersは、次のエラーを防ぐためのものです。

リクエストヘッダーフィールドContent-Typeは、プリフライト応答のAccess-Control-Allow-Headersでは許可されていません。

このエラーは、現在要求されているContent-Typeの値がサポートされていないことを示しています。実際、「application / json」タイプのリクエストを開始しました。これにはコンセプトが含まれます：プリフライトリクエスト（プリフライトリクエスト）、以下の「プリフライトリクエスト」の紹介をご覧ください。

3. Access-Control-Allow-Methodsは、次のエラーを防ぐためのものです。

Content-Typeは、プリフライト応答のAccess-Control-Allow-Headersでは許可されていません。

4. OPTIONSに204リターンを追加して、POSTリクエストの送信時にNginxが引き続きアクセスを拒否するエラーを処理します。
「プリフライトリクエスト」を送信する場合は、メソッドOPTIONSを使用する必要があるため、サーバーはこのメソッドを許可する必要があります。

プリフライトリクエスト

実際、上記の構成にはW3C標準が含まれています。CROS、フルネームはクロスオリジンリソースシェアリング（クロスオリジンリソースシェアリング）であり、クロスドメインリクエストを解決するために提案されています。

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

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

したがって、application / 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.