가장 완벽한 Ajax 크로스 도메인 솔루션

이 기사에서는 가장 포괄적인 Ajax 크로스 도메인 솔루션을 공유할 것입니다. 제가 처음 프론트 엔드 개발을 접한 이후로 <code><span style="font-size: 14px;">跨域</span>这个词就一直以很高的频率在身边重复出现，一直到现在，已经调试过N个跨域相关的问题了，16年时也整理过一篇相关文章，但是感觉还是差了点什么，于是现在重新梳理了一下。

题纲

关于跨域，有N种类型，本文只专注于<span style="font-size: 14px;">ajax请求跨域</span>cross-domain이라는 단어가 반복되었습니다. 지금까지 N 크로스도메인 관련 이슈를 디버깅해 보았는데, 2016년에도 관련 글을 정리했는데 뭔가 부족한 느낌이 들어서 지금 다시 정리하게 되었습니다.

• 질문 개요

크로스 도메인에는 N가지 유형이 있습니다. 이 글에서는
<li>ajax request cross-domain<p></p> </li>(, ajax cross-domain only)에만 중점을 둡니다. 브라우저 "동일 출처" "전략의 일부"에 속하며 기타에는 쿠키 크로스 도메인, iframe 크로스 도메인, LocalStorage 크로스 도메인 등이 포함됩니다(여기에서는 소개되지 않음). 내용은 대략 다음과 같습니다.

• Ajax 크로스 도메인이란 무엇입니까

• 원칙

• 성능(발생한 일부 문제 및 해결 방법 정리)

• 아자 해결 방법 x 크로스 도메인

• JSONP 방식

• CORS 방식

• 프록시 요청 방식

• Ajax 도메인 간 분석 방법

http 패킷 캡처 분석

예제

Ajax 크로스란 무엇입니까? 도메인

ajax 크로스 도메인

ajax의 요청 크로스 도메인 오류 문제가 주된 원인입니다. "동일 출처 정책"을 참조할 수 있습니다.

브라우저의 동일 출처 정책 및 우회 방법(Ruan Yifeng)

CORS 요청 원칙

CORS은 W3C 표준이며 전체 이름은 "Cross- 원본 리소스 공유". 이를 통해 브라우저는 교차 출처 서버에 XMLHttpRequest 요청을 발행할 수 있으므로 AJAX가 동일한 출처에서만 사용될 수 있다는 제한을 극복할 수 있습니다.

기본적으로 현재의 모든 브라우저는 CORS 표준을 구현했습니다. 실제로 거의 모든 브라우저 Ajax 요청은 CORS 메커니즘을 기반으로 하지만 프런트 엔드 개발자는 이에 대해 신경 쓰지 않을 수 있습니다(그래서 실제로 CORS는 이제 솔루션입니다). 주로 배경을 구현하는 방법을 고려합니다).

CORS에 대해 도메인 간 리소스 공유 CORS 자세한 설명(Ruan Yifeng)

을 읽어보는 것이 좋습니다. 또한 구현 도식 다이어그램(간략화된 버전)도 있습니다.

간단한 요청인지 확인하는 방법

• 브라우저에서는 CORS 요청을 단순 요청과 단순하지 않은 요청이라는 두 가지 범주로 나눕니다. 다음 두 가지 조건이 동시에 충족된다면, 간단한 요청입니다.

• 요청 방법은 HEAD, GET, POST 세 가지 방법 중 하나입니다.

  Accept-Language

• Content-Language

• Last-Event-ID

• Content-Type(application/x-www-form-urlen coded, multipart/form-data, text/plain 세 가지 값으로 제한)
위 두 가지를 충족하지 않는 모든 요청 조건은 동시에 간단하지 않은 요청입니다.

ajax 크로스 도메인 성능

솔직히 처음에는 글을 정리해서 해결책으로 사용했는데 나중에 보니 아직도 어떻게 하는지 모르시는 분들이 많더라구요 . 시간이 많이 걸리고 노동집약적인 디버깅을 할 수밖에 없습니다. 하지만 분석을 하더라도 해당 성능을 기준으로 크로스 도메인 여부만 판단할 것이므로 이것이 매우 중요합니다.

Ajax 요청 시 도메인 간 현상이 발생하고 해결되지 않으면 다음과 같은 동작이 발생합니다. (참고로 이는 ajax 요청입니다. http 요청은 괜찮지만 ajax는 그렇지 않은 이유를 말하지 마세요. , Ajax에는 크로스 도메인이 수반되기 때문입니다. 따라서 단지 http 요청만으로는 충분하지 않습니다.)

참고: 특정 백엔드 크로스 도메인 구성에 대한 질문 개요를 참조하세요.

첫 번째 현상: <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>No 'Access-Control-Allow-Origin' 헤더가 요청한 리소스에 존재합니다

및 응답에 HTTP 상태 코드 404가 있었습니다.

• 
  이 나타납니다. 이 상황의 이유는 다음과 같습니다.

• 이 ajax 요청은 "비단순 요청"이므로 요청 전에 실행 전 요청(OPTIONS)이 전송됩니다.

서버 측 배경 인터페이스가 OPTIONS 요청을 허용하지 않아 해당 인터페이스 주소를 찾을 수 없습니다

• 해결책: 백엔드에서 옵션 요청을 허용합니다

• 두 번째 현상:

  No '액세스 제어 허용 -Origin' 헤더가 요청한 리소스🎜🎜에 있고🎜🎜응답에 HTTP 상태 코드 405🎜🎜🎜🎜🎜🎜🎜이 현상은 처음과 다릅니다. 이 경우 백그라운드 메소드에서는 OPTIONS 요청을 허용하지만 일부 구성 파일(예: 🎜🎜보안 구성🎜🎜), OPTIONS 요청을 차단하면 이 현상이 발생합니다🎜🎜🎜🎜해결책: 백엔드에서 해당 보안 구성을 닫습니다🎜🎜🎜🎜세 번째 현상: 🎜 🎜요청된 리소스🎜🎜에 'Access-Control-Allow-Origin' 헤더가 없으며 🎜🎜status 200🎜🎜🎜🎜🎜🎜🎜이 현상은 첫 번째와 두 번째와 다릅니다. 서버측 백그라운드는 OPTIONS 요청을 허용하고 인터페이스도 OPTIONS 요청을 허용하지만 헤더가 일치할 때 불일치가 있습니다. 예를 들어 원본 헤더 확인이 일치하지 않습니다. 예를 들어 일부 헤더 지원이 누락되었습니다(예: 공통 X-요청 - 헤더 사용), 서버는 프런트 엔드에 응답을 반환하고 프런트 엔드에서 이를 감지하면 XHR.onerror를 트리거하여 프런트 엔드 콘솔에서 오류를 보고하게 합니다. 🎜🎜네 번째 현상: 🎜🎜heade에는 여러 값 ​​'*,*'🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜현상은 백그라운드 응답 http 헤더 정보에 🎜🎜Access-Control-Allow-Origin:*🎜🎜🎜🎜두 개가 있다는 것입니다. , 이런 문제가 발생합니다. 주된 이유는 도메인 간 구성을 수행하는 사람들이 원리를 이해하지 못하여 .net 백엔드에서 흔히 볼 수 있는 다음과 같은 구성이 반복적으로 발생하기 때문입니다. (보통 원본이 구성됩니다.) web.config에 한 번 추가한 다음 코드에 수동으로 추가합니다. 하나의 원본(예: 코드가 수동으로 반환 값을 설정합니다 *))🎜🎜🎜🎜🎜🎜.net 백엔드에서 흔히 발견됩니다(IIS와 IIS 모두에서 Origin:* 설정). 프로젝트의 webconfig)🎜🎜🎜🎜🎜🎜해결 방법(일대일 대응) :🎜🎜🎜🎜🎜🎜코드에 수동으로 추가한 *는 삭제하고 프로젝트 구성에 있는 것만 사용하는 것을 권장합니다🎜🎜🎜 🎜🎜🎜IIS에서 * 구성을 삭제하고 프로젝트 구성에 있는 구성만 사용하는 것이 좋습니다🎜🎜

Ajax 크로스 도메인 해결 방법

일반적으로 ajax 크로스 도메인 솔루션은 다음과 같이 JSONP 또는 CORS를 통해 해결됩니다. (참고로 JSONP는 더 이상 거의 사용되지 않으므로 JSONP만 이해하세요.)

교차 도메인 문제를 해결하는 JSONP 방법

jsonp는 교차 도메인 문제를 해결하는 비교적 오래된 솔루션입니다(실제로 권장되지 않음). 다음은 간단한 소개입니다(실제 프로젝트에서 JSONP를 사용하려면 일반적으로 JQ 등을 사용합니다. JSONP를 캡슐화하여 ajax 요청을 수행하는 클래스 라이브러리)

구현 원칙

JSONP를 사용하여 도메인 간 솔루션을 해결할 수 있는 이유는 주로 <script> -domain 기능과 JSONP는 이를 활용하여 달성됩니다. 구체적인 원리는 그림에 나와 있습니다</script>

구현 프로세스

JSONP의 구현 단계는 대략 다음과 같습니다. (소스의 기사 참조)

• 클라이언트 웹 <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로 사용됩니다. 이런 식으로 스크립트 태그가 빌드되면 최종 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 웹 서버 교차 도메인 구성(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 배경 구성(익스프레스 프레임워크)

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 이 두 라이브러리 파일은 lib 디렉터리에 있습니다. (해당 프로젝트의 webcontent/WEB-INF/lib/ 아래에 배치하세요.)

Step 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단계: 프로젝트의 Web.xml(App/WEB-INF/web.xml)에 CORS 구성을 추가합니다. 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!