Nginxはクロスドメインの問題を解決し、サードパーティのページを埋め込む

序文

私たち自身のシステムは、サードパーティのシステムからいくつかのコンポーネントをロードする必要があります。計画としては、サードパーティが関連するインターフェースを開発して提供することになっています。私たちはインターフェースを通じてデータを取得し、そのデータを使用してシステムに関連する機能を実装します。

残念ながら、リーダーシップは調整しませんでした。通常の方法が機能しない場合は、何か特別なことをする必要があります。

前述のように、インターフェースを使用してデータを取得して再レンダリングします。これは比較的一般的な方法です。欠点は、関連するモジュールを再実装する必要があり、相手側にインターフェースを開くよう要求することです。

今は、異常なチャネルしか使用できません。たとえば、ページを自社のシステムに直接埋め込むことは簡単に考えられますが、同時にサードパーティのページのスタイルとコンポーネントを制御する必要があります。

困難

上記の方法は、自社システムで iframe を計画し、src 属性を通じてサードパーティのシステムを導入する方法です。
ここでの最大の問題はクロスドメインです。インターネット上で言及されている最も可能性の高い解決策は、postMessage を使用してドメインを越えることです。残念ながら、これには依然としてサードパーティの協力が必要です。

クロスドメイン定義

まず、狭義の相同性とは、ドメイン名、プロトコル、ポートが同じであることを意味します。
クロスドメインとは、ブラウザが他の Web サイトのスクリプトを実行できないことを意味します。これは、ブラウザが JavaScript に実装するセキュリティ制限であるブラウザの同一オリジンポリシーによって発生します。

nginxの機能

リバースプロキシ

URL を設定します。ユーザーがこの URL にアクセスすると、プロキシは実際に必要な URL に誘導されます。

静的と動的の分離

名前が示すように、動的リソース (サーバーの計算が必要) は静的リソース (通常は html、css、js、img などの静的ページに関連するリソースを指します) から分離されます。

達成しようとする

Aアプリケーションはポート80を使用し、サードパーティのBシステムもポート80を使用しているため、Bシステムへのプロキシを区別するためにサフィックスを追加する必要があります。おおよそのURLは次のとおりです。

# AのURL
http://ローカルホスト/
# B 接尾辞付き URL
http://localhost/3 部構成
# Bの実際のURL
http://172.16.1.1/

通常、localhost にアクセスすると、システム A のホームページが表示されます。172.16.1.1 にアクセスすると、システム B のホームページが表示されます。プロキシ URL 経由でアクセスすると、nginx は実際に 172.16.1.1/three-part にプロキシします。はい、テスト時に、サフィックスが引き継がれていることがわかりましたか? ? 私が専門家ではなく、適切に設定していない可能性もありますが、これは私のテストの結果です。

上記の構成の考え方は、2つのアプリケーションに同じIPとポートを持たせ、アプリケーションAのiframeがアプリケーションBのホームページを読み込み、jsを介して操作できるようにすることです。

残念ながら、唯一の方法は、別のポートを設定することです。たとえば、アプリケーション B のプロキシ URL を localhost:81/ に設定します。この方法では、アプリケーション A の iframe に対応するページでアプリケーション B を変更する js を記述することはできません。

最終結果

アプリケーション B で F12 を押すと、ログインしてホームページに入るときに読み込まれる x.min.js ファイルがカプセル化されていることがわかりました。
そこで、ここにトリックがあります。私は js ファイルを直接書き換え、必要なロジックをファイルの最後に配置し、この x.min.js をロードするときに、サードパーティのサーバーで x.min.js をロードするのではなく、自分のサーバーで変更された js ファイルをページにロードさせます。

全体のプロセスの概略図を以下に示します。

以下は私が設定して使用しているnginxの設定です

上流ミール{
    サーバー 10.1.128.58:80;
}
サーバー{
 listen localhost:8001; # nginx は URL と対応するポートの場所を listen する必要があります =/static/mir.min.js {
  ルート C:/r9/bin/resources;
 }
 位置 / {
  # ここでは URL 変数名が使用されており、この変数名はアップストリーム proxy_pass http://mir で定義されていることがわかります。
  # 以下の項目は標準のクロスドメイン構成とみなされるため、コピーするだけです proxy_set_header Host $http_host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Fonwarded-For $proxy_add_x_forwarded_for;
  $request_method = 'OPTIONS'の場合{
   204を返します。
  }
 }
 # 静的リソースの解放場所 ~ \.(gif|jpg|jpeg|css|js|svg)$ {
  proxy_pass http://mir;
  proxy_set_header ホスト $http_host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Fonwarded-For $proxy_add_x_forwarded_for;
  有効期限は30日です。
 }
 # クロスドメインリクエストヘッダーを追加します。add_header 'Access-Control-Allow-Origin' '*';
 add_header 'Access-Control-Allow_Credentials' 'true';
 add_header 'Access-Control-Allow-Headers' 'Authorization、Accept、Origin、DNT、X-CustomHeader、Keep-Alive、User-Agent、X-Requested-With、If-Modified-Since、Cache-Control、Content-Type、Content-Range、Range';
 add_header 'アクセス制御許可メソッド' 'GET、POST、OPTIONS、PUT、DELETE、PATCH';
 #エラーページ 404 /404.html;

 # サーバーのエラーページを静的ページ /50x.html にリダイレクトします
 # 通常のわかりやすいエラーページを設定します error_page 500 502 503 504 /50x.html;
 場所 = /50x.html {
  ルートhtml;
 }

}

nginx の URL マッチングには、最初のマッチング原則という機能があります。各リクエストに対して、上から下まで、最初に一致したルールがあれば、そのルールに設定された URL に直接ジャンプします。

話題外

サードパーティのシステムは実際には通常のシステムであるためです。たとえば、ログインページが標準で付属しています。ログイン手順を処理する必要があります。したがって、x.min.js でサードパーティのシステムが正しくロードされているかどうか、およびログイン操作が必要かどうかを検出する必要があります。同時に、使いやすさのために、マスクレイヤーを追加する必要があります。サードパーティのページをクリーンアップする前に、顧客がそれを見ることができないようにカバーする必要があります。
サードパーティシステムが正しく読み込まれたら、必要に応じて機能を調整したり、スタイルを置き換えたりすることができます。

nginx がクロスドメインの問題を解決し、サードパーティのページを埋め込む方法についての記事はこれで終わりです。サードパーティのページの nginx クロスドメイン埋め込みの詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

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