nginx でクロスドメイン障害修復を構成する方法の例

Nginxのクロスドメイン設定は次のようには機能しません

サーバー{
  聞く 80;
  server_name ローカルホスト;
  
  # インターフェース転送場所 /api/ {
   # クロスドメインリクエストアドレス * をワイルドカードとして許可する add_header 'Access-Control-Allow-Origin' '*';
   # リクエストメソッドをクロスドメインに設定します。add_header 'Access-Control-Allow-Methods' 'GET、POST、OPTIONS、PUT、DELETE';
   # クッキーの送信を許可するかどうかを設定します。add_header 'Access-Control-Allow-Credentials' 'true';
   # リクエスト ヘッダーの設定。ここでワイルドカード文字を設定してみませんか? * add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Data-Type,X-Requested-With,X-Data-Type,X-Auth-Token' はサポートされていないためです。
   # リバースプロキシを設定する proxy_pass 127.0.0.1:8081/;
  }
 }

インターネット上の nginx のクロスドメイン構成は主に上記のバージョンです。ただし、多くの人はそれをコピーするだけで、実際には実践していません。そのため、必要な人に盲目的にコピーせず、分析することを学ぶように思い出させるためにこの記事を書きました。

Nginxは次の設定を変更して有効にします

サーバー{
  聞く 80;
  server_name ローカルホスト;
  
  # インターフェース転送場所 /api/ {
   # クロスドメインリクエストアドレス * をワイルドカードとして許可する add_header 'Access-Control-Allow-Origin' '*';
   # リクエストメソッドをクロスドメインに設定します。add_header 'Access-Control-Allow-Methods' 'GET、POST、OPTIONS、PUT、DELETE';
   # クッキーの送信を許可するかどうかを設定します。add_header 'Access-Control-Allow-Credentials' 'true';
   # リクエスト ヘッダーの設定。ここでワイルドカード文字を設定してみませんか? * add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Data-Type,X-Requested-With,X-Data-Type,X-Auth-Token' はサポートされていないためです。
   
   # オプションリクエスト処理を設定する if ( $request_method = 'OPTIONS' ) { 
    200を返します。
   }
   # リバースプロキシを設定する proxy_pass 127.0.0.1:8081/;
  }
 }

2つのコードの主な違いは次のコード行です。

$request_method = 'OPTIONS' の場合 
  200を返します。
}

ブラウザは、POST リクエストのオプション事前チェックリクエストを送信します。これは主にリクエストヘッダーをサーバーに送信します。サーバーが許可した場合は、実際の POST リクエストが送信されます。したがって、f12 は、POST が 2 つのリクエストを送信することが多いことを示しています。バックエンドの Java コードがオプション要求を処理しないため、オプションインターフェース要求は 403 禁止を報告します。ここで、nginx はインターフェース層に到達せずにオプション要求に直接 200 を返し、ポスト応答ヘッダーを直接許可します。これにより、上記の無効な構成が有効になる可能性があります。

ちょっとした知識ポイント

プロキシパス 127.0.0.1:8081/;

リバースプロキシに追加するかどうかの問題について;

http://localhost/api/user/login にアクセスします。

/ を追加すると、実際のアクセスは 127.0.0.1:8081/user/login になります。
/ がない場合、実際のアクセスは 127.0.0.1:8081/api/user/login になります。

スラッシュを追加すると、すべての /api リクエストがルートディレクトリに転送され、/api が / に置き換えられます。この時点で、インターフェイスパスが変更され、/api のレイヤーが 1 つ減ります。スラッシュなしの場合はどうでしょうか?これは、ドメイン名 127.0.0.1:8081 に転送するときに /api パスが失われないことを意味します。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません: