最も完全な Ajax クロスドメイン ソリューション

この記事では、最も包括的な Ajax クロスドメイン ソリューションについて説明します。私が初めてフロントエンド開発に触れて以来、<code><span style="font-size: 14px;">跨域</span>这个词就一直以很高的频率在身边重复出现，一直到现在，已经调试过N个跨域相关的问题了，16年时也整理过一篇相关文章，但是感觉还是差了点什么，于是现在重新梳理了一下。

题纲

关于跨域，有N种类型，本文只专注于<span style="font-size: 14px;">ajax请求跨域</span>クロスドメイン という言葉が繰り返されてきました。これまで、N 個のクロスドメイン関連の問題をデバッグしてきました。関連記事も 2016 年にまとめましたが、まだ何かが足りないと感じたので、再整理しました。

• 質問の概要

クロスドメインに関してはN種類ありますが、この記事では
<li>ajax requestcross-domain<p></p> </li>(、ajaxクロスドメインのみ)に焦点を当てています。ブラウザに「同一オリジン」「戦略の一部」に属し、他にはCookieクロスドメイン、iframeクロスドメイン、LocalStorageクロスドメインなどが含まれます（ここでは紹介していません）、内容は大まかに以下の通りです:

• Ajaxクロスドメインとは

• 原理

• パフォーマンス(発生したいくつかの問題と解決策を整理)

• jax クロスドメイン

• JSONPメソッド

• CORSメソッド

• Proxyリクエストメソッド

• Ajaxクロスドメインの解析方法

httpパケットキャプチャ分析

いくつかの例

ajax クロスとは ドメインの原理

ajax クロスドメイン

ajax には、ブラウザのリクエスト クロスドメイン エラーの問題が発生します。 「同一生成元ポリシー」

ブラウザの同一生成元ポリシーとその回避方法を参照できます(Ruan Yifeng)

CORSリクエスト原則

CORSはW3C標準であり、正式名は「Cross-オリジンリソースの共有」。これにより、ブラウザーがクロスオリジン サーバーに XMLHttpRequest リクエストを発行できるようになり、AJAX が同じオリジンからのみ使用できるという制限が克服されます。

基本的に、現在のすべてのブラウザーは CORS 標準を実装しています。実際、ほとんどすべてのブラウザーの Ajax リクエストは CORS メカニズムに基づいていますが、フロントエンド開発者はそれを気にしていない可能性があります (つまり、実際、CORS は現在、解決策は次のとおりです)。主に背景を実装する方法を検討します)。

CORS については、クロスドメイン リソース共有 CORS の詳細な説明 (Ruan Yifeng) を読むことを強くお勧めします

さらに、実装概略図 (簡略版) もここにあります:

単純なリクエストかどうかを判断する方法

• ブラウザは、CORS リクエストを単純なリクエストとそれほど単純ではないリクエストの 2 つのカテゴリに分類します。以下の2つの条件を同時に満たしていれば簡単なリクエストです。

• リクエストメソッドは次の 3 つのメソッドのいずれかです: HEAD、GET、POST

  Accept-Language

• Content-Language

• Last-Event-ID

• Content-Type (application/x-www-form-urlen coded、multipart/form-data、text/plainの3つの値に限定)
上記2つを満たさないリクエスト同時に条件を設定することは単純ではありません。

ajaxクロスドメインパフォーマンス

正直、最初は記事にまとめて解決策として使っていたのですが、後になってみたらまだやり方が分からない人が多いことが分かりました。デバッグするしかありませんが、時間と労力がかかります。ただし、分析してもクロスドメインかどうかは対応するパフォーマンスで判断するだけなので、これは非常に重要です。

ajax リクエストを行う際に、クロスドメイン現象が発生し、それが解決されていない場合、次の動作が発生します: (これは ajax リクエストであることに注意してください。なぜ http リクエストは OK ですが、ajax がダメなのかは述べないでください) 、ajax にはクロスドメインが伴うため、http リクエスト OK だけでは十分ではありません)

注: 特定のバックエンドのクロスドメイン構成については、質問の概要を参照してください。

最初の現象: <code><span style="font-size: 14px;">No 'Access-Control-Allow-Origin' header is present on the requested resource</span>,并且<span style="font-size: 14px;">The response had HTTP status code 404</span>

出现这种情况的原因如下：

• 本次ajax请求是“非简单请求”,所以请求前会发送一次预检请求(OPTIONS)

• 服务器端后台接口没有允许OPTIONS请求,导致无法找到对应接口地址

解决方案: 后端允许options请求

第二种现象:<code><span style="font-size: 14px;">No 'Access-Control-Allow-Origin' header is present on the requested resource</span>,并且<span style="font-size: 14px;">The response had HTTP status code 405</span>

这种现象和第一种有区别,这种情况下，后台方法允许OPTIONS请求,但是一些配置文件中(如<span style="font-size: 14px;">安全配置</span>),阻止了OPTIONS请求,才会导致这个现象

解决方案: 后端关闭对应的安全配置

第三种现象:<code><span style="font-size: 14px;">No 'Access-Control-Allow-Origin' header is present on the requested resource</span>,并且<span style="font-size: 14px;">status 200</span>

这种现象和第一种和第二种有区别,这种情况下，服务器端后台允许OPTIONS请求,并且接口也允许OPTIONS请求,但是头部匹配时出现不匹配现象

比如origin头部检查不匹配,比如少了一些头部的支持(如常见的X-Requested-With头部),然后服务端就会将response返回给前端,前端检测到这个后就触发XHR.onerror,导致前端控制台报错

解决方案: 后端增加对应的头部支持

第四种现象:<span style="font-size: 14px;">heade contains multiple values '*,*'</span>

表现现象是，后台响应的http头部信息有两个<span style="font-size: 14px;">Access-Control-Allow-Origin:*</span> 要求されたリソースに 'Access-Control-Allow-Origin' ヘッダーが存在しません

、および 応答には HTTP ステータス コード 404 がありました

• 
  が表示されますこの状況の理由は次のとおりです:

• この ajax リクエストは「非単純リクエスト」であるため、リクエストの前にプリフライト リクエスト (OPTIONS) が送信されます

サーバー側の背景インターフェイスは OPTIONS リクエストを許可しないため、対応するインターフェイス アドレスが見つからなくなります

• 解決策: バックエンドはオプション リクエストを許可します

• 2 番目の現象:

  No 'Access-Control-Allow -Origin' ヘッダーが要求されたリソースに存在します🎜🎜、および🎜🎜応答には HTTP ステータス コード 405 がありました🎜🎜🎜🎜🎜🎜🎜この現象は最初の現象とは異なります。この場合、バックグラウンド メソッドでは OPTIONS リクエストが許可されていますが、構成ファイル (🎜🎜セキュリティ構成🎜🎜 など) を使用して OPTIONS リクエストをブロックすると、この現象が発生します🎜🎜🎜🎜解決策: バックエンドで対応するセキュリティ構成を閉じます🎜🎜🎜🎜 3 番目の現象: 🎜 🎜要求されたリソースに「Access-Control-Allow-Origin」ヘッダーが存在しません🎜🎜、および 🎜🎜status 200🎜🎜🎜🎜🎜🎜🎜この現象は、1つ目と2つ目とは異なります。サーバー側のバックグラウンドでは OPTIONS リクエストが許可されており、インターフェイスでも OPTIONS リクエストが許可されていますが、ヘッダーが一致すると不一致が発生します。たとえば、オリジンのヘッダー チェックが一致しない、たとえば、一部のヘッダー サポートが欠落しているなどです。 X-Requested -With header)、フロントエンドがこれを検出すると、サーバーはフロントエンドに応答を返し、XHR.onerror がトリガーされ、フロントエンドコンソールにエラーが報告されます。 🎜🎜4 番目の現象: 🎜🎜heade に複数の値 '*,*' が含まれています🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜現象としては、バックグラウンドレスポンスのHTTPヘッダー情報に🎜🎜Access-Control-Allow-Origin:*🎜🎜🎜🎜Toが2つあることです。正直に言うと、この種の問題が発生する主な理由は、クロスドメイン構成を実行する人が原理を理解していないため、次のような構成が繰り返されることです。 🎜🎜🎜🎜🎜🎜 .net バックエンド (通常はオリジンは web.config で一度設定され、コードで手動で追加されます。オリジンは 1 つです (たとえば、コードは return * を手動で設定します))🎜🎜🎜🎜🎜🎜 .net バックエンドでよく見られます (Origin:* を設定します) IIS とプロジェクトの webconfig の両方)🎜🎜🎜🎜🎜🎜解決策 (1 対 1 の対応):🎜🎜🎜🎜🎜🎜 コード内に手動で追加された * を削除し、プロジェクト設定内の * のみを使用することをお勧めします。 🎜🎜🎜🎜🎜🎜IIS の下の構成を削除し、プロジェクト構成内の構成のみを使用することをお勧めします🎜🎜

Ajax クロスドメインの解決方法

一般に、Ajax クロスドメイン ソリューションは、次のように JSONP または CORS を通じて解決されます: (JSONP はもうほとんど使用されていないので、JSONP についてだけ理解してください)

クロスドメインの問題を解決するための JSONP メソッド

jsonp は、クロスドメインの問題を解決するための比較的古いソリューションです (実際には推奨されません) ここで簡単に紹介します (実際のプロジェクトで JSONP を使用したい場合は、一般的には JQ などを使用します。Ajax リクエストを実行するために JSONP をカプセル化するクラス ライブラリ)

実装原理

JSONP を使用してクロスドメイン ソリューションを解決できる理由は、主に <script> スクリプトにクロスドメインがあるためです。 -domain 機能、および JSONP はこれを活用することで実現されます。具体的な原理を図に示します</script>

実装プロセス

JSONPの実装手順は大まかに以下の通りです(ソース記事参照)

• クライアントWebページは <script> 要素を追加することで追加され、サーバーから JSON データをリクエストします。このアプローチは同一生成元ポリシーによって制限されません</script>

  <span style="font-size: 14px;">function addScriptTag(src) {<br>  var script = document.createElement('script');<br>  script.setAttribute("type","text/javascript");<br>  script.src = src;<br>  document.body.appendChild(script);<br>}<br><br>window.onload = function () {<br>  addScriptTag('http://example.com/ip?callback=foo');<br>}<br><br>function foo(data) {<br>  console.log('response data: ' + JSON.stringify(data));<br>};                      <br>    <br></span>

  リクエストするとき、インターフェイス アドレスはビルドされたスクリプト タグの src として使用されますこのようにして、script タグが構築されると、最終的な src インターフェースによって返されるコンテンツが、サーバーの対応するインターフェースによって返されるパラメーターの外側に追加されます。このとき、ブラウザが foo 関数を定義していれば、すぐに関数が呼び出されます。パラメータとしての JSON データは文字列ではなく JavaScript オブジェクトとして扱われるため、JSON.parse を使用する手順が不要になります。

• 一般的なJSONPインターフェースと通常のインターフェースが返すデータには違いがあるため、インターフェースをJSONO互換にする場合は、対応するコールバックキーワードパラメータがあるかどうかを判断する必要があることに注意してください。 . そうであれば、それは JSONP リクエストであり、JSONP が返されます。それ以外の場合は、通常のデータが返されます

使用上の注意

• そのため、JSONP は「GET」のみになります。 " リクエストがあり、より複雑な POST やその他のリクエストを行うことができないため、そのような状況に遭遇した場合は、次の CORS を参照してクロスドメインの問題を解決する必要があります (したがって、現在は基本的に排除されています)

CORS はクロスドメインの問題を解決します-ドメインの問題

CORS の原理は上で紹介しました。ここで主に紹介するのは、実際のプロジェクトにおいて、問題を解決するためにバックエンドをどのように構成すべきかということです (プロジェクトの実践の多くはバックエンドによって解決されるため)。 )、一般的なバックエンド ソリューションをいくつか示します: PHP バックグラウンド構成

PHP バックエンド構成はすべてのバックエンドの中で最も単純で、以下の手順に従ってください:

ステップ 1: PHP を構成するクロスドメインを許可するバックエンド

<span style="font-size: 14px;">foo({<br>  "test": "testData"<br>});                     <br></span>

ステップ 2: Apache Web サーバーのクロスドメインの設定 (httpd.conf 内)

• 元のコード

  <span style="font-size: 14px;"><?php <br/>header('Access-Control-Allow-Origin: *');<br>header('Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept');<br>//主要为跨域CORS配置的两大基本信息,Origin和headers<br></span>

は、以下のコード

<span style="font-size: 14px;"><directory></directory><br>    AllowOverride none<br>    Require all denied<br><br></span>

Node.jsのバックグラウンド設定(Express Framework)

Node.jsのバックグラウンドも比較的簡単に設定できます。 Express を使用して次のように設定するだけです:

<span style="font-size: 14px;"><directory></directory><br>    Options FollowSymLinks<br>    AllowOverride none<br>    Order deny,allow<br>    Allow from all<br><br></span>

JAVA バックグラウンド設定

JAVA バックグラウンド設定は次の手順に従うだけです:

ステップ 1: 依存する jar パッケージを取得します

ダウンロードcors -filter-1.7.jar、java-property-utils-1.9.jar これら 2 つのライブラリ ファイルは lib ディレクトリに配置されます。 (対応するプロジェクトの webcontent/WEB-INF/lib/ の下に配置します)

ステップ 2: プロジェクトが Maven でビルドされている場合は、次の依存関係を pom.xml に追加してください: (Maven でない場合) 、無視してください)

• <span style="font-size: 14px;">app.all('*', function(req, res, next) {<br>    res.header("Access-Control-Allow-Origin", "*");<br>    res.header("Access-Control-Allow-Headers", "X-Requested-With");<br>    res.header("Access-Control-Allow-Methods", "PUT,POST,GET,DELETE,OPTIONS");<br>    res.header("X-Powered-By", ' 3.2.1')<br>        //这段仅仅为了方便返回json而已<br>    res.header("Content-Type", "application/json;charset=utf-8");<br>    if(req.method == 'OPTIONS') {<br>        //让options请求快速返回<br>        res.sendStatus(200); <br>    } else { <br>        next(); <br>    }<br>});<br></span>

  バージョンは最新の安定バージョン、CORSフィルターである必要があります

ステップ3: CORS構成をプロジェクトのWeb.xmlに追加します(App/WEB-INF/web. xml)

• <span style="font-size: 14px;"><dependency><br>    <groupid>com.thetransactioncompany</groupid><br>    <artifactid>cors-filter</artifactid><br>    <version>[ version ]</version><br></dependency><br></span>

上記の設定ファイルは最初のフィルターとして web.xml の前に配置する必要があることに注意してください (フィルターは複数存在する可能性があります)

• 第四步:可能的安全模块配置错误(注意，某些框架中-譬如公司私人框架，有安全模块的，有时候这些安全模块配置会影响跨域配置，这时候可以先尝试关闭它们)

NET后台配置

.NET后台配置可以参考如下步骤:

• 第一步:网站配置

打开控制面板，选择管理工具,选择iis;右键单击自己的网站，选择浏览;打开网站所在目录,用记事本打开web.config文件添加下述配置信息,重启网站

请注意,以上截图较老,如果配置仍然出问题,可以考虑增加更多的headers允许,比如:

<span style="font-size: 14px;">"Access-Control-Allow-Headers":"X-Requested-With,Content-Type,Accept,Origin"            <br></span>

• 第二步:其它更多配置,如果第一步进行了后,仍然有跨域问题，可能是:

• 接口中有限制死一些请求类型(比如写死了POST等)，这时候请去除限    制

• 接口中，重复配置了<span style="font-size: 14px;">Origin:*</span>，请去除即可

• IIS服务器中，重复配置了<span style="font-size: 14px;">Origin:*</span>，请去除即可

代理请求方式解决接口跨域问题

注意，由于接口代理是有代价的，所以这个仅是开发过程中进行的。

与前面的方法不同，前面CORS是后端解决，而这个主要是前端对接口进行代理，也就是:

• 前端ajax请求的是本地接口

• 本地接口接收到请求后向实际的接口请求数据，然后再将信息返回给前端

• 一般用node.js即可代理

关于如何实现代理，这里就不重点描述了，方法和多，也不难，基本都是基于node.js的。

搜索关键字<span style="font-size: 14px;">node.js</span>,<span style="font-size: 14px;">代理请求</span>即可找到一大票的方案。

如何分析ajax跨域

上述已经介绍了跨域的原理以及如何解决，但实际过程中，发现仍然有很多人对照着类似的文档无法解决跨域问题，主要体现在，前端人员不知道什么时候是跨域问题造成的，什么时候不是，因此这里稍微介绍下如何分析一个请求是否跨域:

抓包请求数据

第一步当然是得知道我们的ajax请求发送了什么数据，接收了什么，做到这一步并不难，也不需要<span style="font-size: 14px;">fiddler</span>等工具，仅基于<span style="font-size: 14px;">Chrome</span>即可

• <span style="font-size: 14px;">Chrome</span>浏览器打开对应发生ajax的页面，<span style="font-size: 14px;">F12</span>打开<span style="font-size: 14px;">Dev Tools</span>

• 发送ajax请求

• 右侧面板-><span style="font-size: 14px;">NetWork</span>-><span style="font-size: 14px;">XHR</span>，然后找到刚才的ajax请求，点进去

示例一(正常的ajax请求)

上述请求是一个正确的请求，为了方便，我把每一个头域的意思都表明了，我们可以清晰的看到，接口返回的响应头域中，包括了

<span style="font-size: 14px;">Access-Control-Allow-Headers: X-Requested-With,Content-Type,Accept<br>Access-Control-Allow-Methods: Get,Post,Put,OPTIONS<br>Access-Control-Allow-Origin: *<br></span>

所以浏览器接收到响应时，判断的是正确的请求，自然不会报错，成功的拿到了响应数据。

示例二(跨域错误的ajax请求)

为了方便，我们仍然拿上面的错误表现示例举例。

这个请求中，接口Allow里面没有包括<span style="font-size: 14px;">OPTIONS</span>，所以请求出现了跨域、

这个请求中，<span style="font-size: 14px;">Access-Control-Allow-Origin: *</span>出现了两次，导致了跨域配置没有正确配置，出现了错误。

更多跨域错误基本都是类似的，就是以上三样没有满足(Headers,Allow,Origin)，这里不再一一赘述。

示例三(与跨域无关的ajax请求)

当然，也并不是所有的ajax请求错误都与跨域有关，所以请不要混淆，比如以下:

比如这个请求，它的跨域配置没有一点问题，它出错仅仅是因为request的<span style="font-size: 14px;">Accept</span>和response的<span style="font-size: 14px;">Content-Type</span>不匹配而已。

更多

基本上都是这样去分析一个ajax请求，通过<span style="font-size: 14px;">Chrome</span>就可以知道了发送了什么数据，收到了什么数据，然后再一一比对就知道问题何在了。

写在最后的话

跨域是一个老生常谈的话题，网上也有大量跨域的资料，并且有不少精品(比如阮一峰前辈的)，但是身为一个前端人员不应该浅尝而止，故而才有了本文。

漫漫前端路，望与诸君共勉之！

相关推荐：

php处理ajax请求与ajax跨域

AJAX跨域请求的详细介绍

jquery ajax跨域解决方法(json方式)

以上が最も完全な Ajax クロスドメイン ソリューションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。