クロスドメインの 5 つの最も一般的なソリューション

Web アプリケーションを開発するときの一般的な質問は、クロスオリジン リクエストを処理する方法です。クロスオリジン リクエストとは、さまざまなソースからのリクエストを指し、ブラウザによって制限され、正常に処理できない場合があります。この投稿では、クロスオリジン リクエストの一般的なソリューションを探り、それぞれの長所と短所を理解します。

1.JSONP

JSONP は、ブラウザの機能を利用する一般的なクロスドメイン リクエスト ソリューションです。他のドメインの JavaScript リソースは <script> タグを介してロードできます。JSONP の動作原理は、サーバー側で JavaScript 関数を生成し、クライアントに渡す必要があるデータをパラメーターとして関数に渡すことです。次に、クライアントは <script> タグを作成して JavaScript 関数をロードし、ロード後に関数が自動的に実行されることで、クロスドメイン リクエストが実現されます。

JSONP の利点は、使いやすく、互換性が高いことです。しかし、それにはいくつかの欠点もあります。まず、JSONP は GET リクエストのみをサポートし、POST などの他のタイプのリクエストはサポートしていません。次に、<script> タグを介して JavaScript リソースをロードするため、XHR オブジェクトを使用して柔軟な制御と処理を行うことができません。

2.CORS

CORS は、最新の Web アプリケーションで一般的に使用されるクロスオリジン リクエスト ソリューションの 1 つです。CORS (Cross-Origin Resource Sharing) は、サーバーがそのリソースにアクセスできるドメインを指定できる HTTP ヘッダーベースのメカニズムです。CORS の動作原理は、クライアントがクロスドメイン リクエストを開始すると、ブラウザーが OPTIONS リクエスト (プリフライト リクエスト) を送信することです。このリクエストには、Origin、Access-Control-Request-Method、Access- Control-Request-Headers など リクエストを受信した後、サーバーは HTTP ヘッダーに Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers などの情報を追加して、クロスドメインを許可します。リクエスト。次に、ブラウザは、サーバーから返された HTTP ヘッダー情報に従って、クロスドメイン リクエストを許可するかどうかを決定します。

CORS の利点は、柔軟なリクエスト タイプをサポートしているため、開発者はクライアントとサーバー間で柔軟な対話を実行できることです。しかし、それにはいくつかの欠点もあります。まず、CORS にはサーバー サポートが必要であり、有効にするにはいくつかの構成が必要です。次に、CORS にはいくつかのセキュリティ リスクがあります。たとえば、サーバーが Access-Control-Allow-Origin ヘッダーを * に設定すると、すべてのドメインがそのリソースにアクセスできるようになり、セキュリティ上の問題が発生する可能性があります。

3. WebSocket

WebSocket は、TCP プロトコルに基づく全二重通信プロトコルであり、クライアントとサーバーの間でリアルタイムの双方向通信を実行できます。WebSocket は TCP プロトコルに基づいているため、ブラウザーの同一生成元ポリシーの制限をバイパスして、クロスドメイン通信を実現できます。

WebSocket の利点は、リアルタイムの双方向通信をサポートし、開発者がクライアントとサーバーの間で効率的なデータ転送を実行できることです。しかし、それにはいくつかの欠点もあります。まず、WebSocket にはサーバー サポートが必要です。すべてのサーバーが WebSocket プロトコルをサポートしているわけではありません。次に、WebSocket は全二重プロトコルであるため、開発者はメッセージ処理とルーティング ロジックを自分で実装する必要があります。

4. エージェント

プロキシは、一般的なクロスドメイン リクエスト ソリューションの 1 つです。プロキシの動作原理は、同一生成元ポリシーで許可されている場合、クライアントを介して独自のサーバーに要求を送信し、サーバーがその要求をターゲット サーバーに転送し、応答をクライアントに返すことです。このとき、クライアントと自サーバー間のリクエストは同一オリジンなので、同一オリジンポリシーによる制限を受けません。

プロキシの利点は、柔軟で使いやすいことです.開発者自身のサーバーを介してクロスドメイン要求を行うか、サードパーティのプロキシサーバーを使用できます. しかし、それにはいくつかの欠点もあります。まず、プロキシはサーバーに負荷と待ち時間を追加します。これは、要求をターゲット サーバーに転送し、応答をクライアントに返す必要があるためです。第 2 に、プロキシはセキュリティ リスクをもたらす可能性があります。たとえば、プロキシ サーバーが攻撃または悪用される可能性があります。

5.ポストメッセージ

PostMessage は、HTML5 標準に基づくドキュメント間通信メカニズムであり、異なるウィンドウ、タブ、またはブラウザー間で通信できます。PostMessage の動作原理は、ウィンドウ オブジェクトの postMessage メソッドを介してメッセージを送信し、ターゲット ウィンドウの onmessage イベントでメッセージを受信することです。PostMessage を通じて、開発者は異なるドメイン間で安全なクロスドメイン通信を行うことができます。

PostMessage の利点は、安全で信頼性が高く、サーバーのサポートに依存することなく、開発者独自のスクリプトを介してクロスドメイン リクエストを作成できることです。しかし、それにはいくつかの欠点もあります。まず、PostMessage では、開発者がメッセージ処理とルーティング ロジックを自分で実装する必要があります。次に、PostMessage は HTML5 標準に基づくメカニズムであるため、古いバージョンのブラウザーはサポートされていません。

結論は

上記は一般的なクロスドメイン リクエスト ソリューションであり、各ソリューションには長所と短所があります。開発者がソリューションを選択する場合、特定のビジネス ニーズとシナリオに従って最適なソリューションを選択する必要があります。柔軟なリクエスト タイプとインタラクション メソッドが必要な場合は、CORS または WebSocket を選択できます。安全で信頼性の高いクロスドメイン リクエストが必要な場合は、PostMessage を選択できます。柔軟で使いやすいソリューションが必要な場合は、JSONP またはプロキシー。どちらのオプションを選択する場合でも、その長所と短所、および考えられるセキュリティ リスクを慎重に検討する必要があります。

おすすめ

転載: blog.csdn.net/tyxjolin/article/details/130413693