ajax跨域的解决办法,ajax实现跨域三种方法

  ajax跨域的解决办法,ajax实现跨域三种方法

  从前端开发开始,“跨域”这个词就在身边高频重复。到现在为止,已经调试了N个跨域相关问题,16年编了一篇相关文章,但是还是觉得有些不对,所以现在又重新梳理了一遍。

  我个人的知识有限。如有错误请见谅,欢迎提出问题。另外,请不要喷这个标题~

  主题大纲

  关于跨域,有n种。本文只关注ajax请求跨域(ajax跨域只是浏览器“同源策略”的一部分,其他还有Cookie跨域、iframe跨域、LocalStorage跨域等。这里不做介绍)。内容如下:

  什么是ajax跨域

  原则

  性能(整理一些问题和解决方案)

  如何解决ajax跨域

  JSONP模式

  CORS模式

  代理请求模式

  如何分析ajax跨域

  http数据包捕获分析

  一些例子

  什么是ajax跨域

  ajax的跨域原理

  ajax请求跨域错误的问题主要是因为浏览器的“同源策略”。可以参考浏览器的同源政策及其规避方法(阮一峰)。

  CORS请求原则

  CORS是W3C标准,全称是“跨源资源共享”。它允许浏览器向跨源服务器发出XMLHttpRequest请求,从而克服了AJAX只能从同一个源使用的限制。

  基本上,目前所有的浏览器都实现了CORS标准。事实上,几乎所有的浏览器ajax请求都是基于CORS机制的,只是前端开发人员平时可能不会在意。(所以,实际上CORS解决方案现在主要考虑的是如何在后台实现)。

  关于CORS,强烈推荐阅读跨域资源共享CORS(阮一峰)的详解

  此外,这里还编制了一个实现原理图(简化版):

  如何辨别是不是单纯的请求?

  浏览器CORS请求分为两类:简单请求和不那么简单的请求。只要满足以下两个条件,就是简单的要求。

  请求方法是以下三种方法之一:head、get和post。

  HTTP的报头信息不超过以下字段:

  接受

  接受语言

  内容语言

  最后事件ID

  内容类型(仅限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain)

  凡是不同时满足以上两个条件的,都是非简单要求。

  ajax的跨域性能

  说实话,我一开始是编了一篇文章,然后作为解决方案,但是后来发现还是有很多人还是不行。只能是费时费力的调试。但是,即使我分析,也只会根据相应的表现来判断是否跨域,所以这一点很重要。

  ajax请求时,如果出现跨域现象而没有解决,会有如下表现:(注意是ajax请求,请不要说为什么http请求可以,ajax不行,因为ajax是伴随跨域的,所以仅仅http请求可以是不行的)

  注:具体后端跨域配置请参考标题位置。

  第一个现象:请求的资源上没有“access-control-allow-origin”头,响应的http状态代码是404。

  其原因如下:

  这个ajax请求是一个“不简单的请求”,所以在请求之前会发送一个选项。

  服务器后台接口不允许OPTIONS请求,因此找不到相应的接口地址。

  解决方案:后端允许选项请求。

  第二个现象:请求的资源上没有“access-control-allow-origin”头,响应的http状态代码是405。

  这个现象和第一个不一样。在这种情况下,后台方法允许OPTIONS请求,但一些配置文件(如安全配置)会阻止OPTIONS请求,这就会导致这种现象。

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

  第三个现象:请求的资源上没有“access-control-allow-origin”头,状态是200。

  这个现象跟第一个和第二个是不一样的。在这种情况下,服务器端后台允许OPTIONS请求,接口也允许OPTIONS请求,但是头匹配时存在不匹配。

  比如origin头校验不匹配,比如缺少对某些头的支持(比如常见的X-Requested-With头),然后服务器会把响应返回给前端。前端检测到这一点后,会触发XHR.onerror,导致前端控制台报错。

  解决方法:在后端增加相应的头部支撑。

  第四个现象:head包含多个值 *,*

  现象是后台响应的http头信息有两个Access-Control-Allow-Origin:*

  说实话,这类问题的主要原因是做跨域配置的人不懂原理,导致重复配置,比如:

  常见于的背景。net(一般在web.config中配置一次原点,然后再手动添加到代码中(比如代码手动设置return *))

  常见于的背景。net(设置原点:*在项目的IIS和webconfig中)

  解决方案(一一对应):

  建议删除代码中手动添加的*,在项目配置中只使用*。

  建议删除IIS下的配置*,只使用项目配置中的那个。

  如何解决ajax跨域

  一般ajax跨域解决方案都是通过JSONP或者CORS来解决,比如如下:(注意JSONP几乎已经不用了,所以JSONP可以理解。)

  JSONP解决跨域问题

  Jsonp是解决跨域问题的老方案(实践中不推荐)。下面简单介绍一下(如果要在实际项目中使用JSONP,一般会使用封装JSONP的JQ等类库来进行ajax请求)

  实现原则

  JSONP之所以可以用来解决跨域解决方案,主要是因为

  实现进程

  JSONP的实现步骤大致如下(参考源码中的文章)

  客户端网页网页是通过添加

  functionaddScriptTag(src){

  var script=document . createelement( script );

  script.setAttribute(type , text/JavaScript );

  script.src=src

  document.body.appendChild(脚本);

  }

  window.onload=function(){

  addScriptTag( http://example . com/IP?callback=foo’);

  }

  functionfoo(数据){

  console.log(响应数据: JSON . stringify(data));

  };

  请求时,接口地址作为构建脚本标签的src,所以在构建脚本标签时,最终的src就是接口返回的内容。

  服务器对应的接口在返回参数之外增加了一个函数包装层。

  注意一般JSONP接口返回的数据和普通接口是有区别的,所以如果要让接口兼容JSONO,就要判断是否有对应的callback关键字参数。如果有,则是JSONP请求,返回JSONP数据;否则,它返回正常数据。

  注意使用

  基于JSONP的实现原理,JSONP只能是一个“GET”请求,复杂的POST等请求是不能发出的。所以,在那种情况下,我们不得不参考下面的CORS来解决跨域问题(所以现在基本消除了)。

  CORS解决跨领域问题

  上面已经介绍了CORS的原理。这里主要介绍的是在实际项目中应该如何配置后端来解决问题(因为大量的项目实践都是由后端解决的)。以下是一些常见的后端解决方案:

  PHP的后台配置

  PHP在后台的配置几乎是所有后台中最简单的。请遵循以下步骤:

  步骤1:配置Php后台以允许跨域

  ?php头( Access-Control-Allow-Origin:*);

  header( Access-Control-Allow-Headers:Origin,X-Requested-With,Content-Type,Accept));

  //两个基本信息,Origin和headers,主要是为跨域CORS配置的。

  app.all(* ,function(req,res,next){

  RES . header( Access-Control-Allow-Origin , * );

  RES . header( Access-Control-Allow-Headers , X-Requested-With );

  RES . header( Access-Control-Allow-Methods , PUT,POST,GET,DELETE,OPTIONS );

  RES . header(“X-Powered-By”,“3.2.1”)

  //这一段只是为了方便返回json

  res.header(Content-Type , application/JSON;);

  if(req.method==OPTIONS){

  //让选项请求快速返回

  RES . send status(200);

  }否则{

  next();

  }

  });

  第一步:获取依赖的jar包,下载CORS-过滤器-1.7.jar和Java-property-utils-1.9.jar,放在lib目录下。(放在对应项目的webcontent/WEB-INF/lib/下)

  第二步:如果项目是用maven构建的,请将以下依赖项添加到pom.xml中:(请忽略非Maven)

  groupId com . thetransactioncompany/groupId

  artifact id CORS-过滤器/artifactId

  版本[版本]/版本

  /依赖关系

  过滤器

  !-带参数的CORS滤波器-

  过滤器名称CORS/过滤器名称

  filter-class com . thetransactioncompany . CORS . CORS filter/filter-class

  !-注意:所有参数都是可选的,如果提交了CORS

  过滤器将退回到各自的默认值。

  -

  初始化参数

  param-name CORS . allowgenerichttprequests/param-name

  参数值真/参数值

  /init-param

  初始化参数

  param-name CORS . allow origin/param-name

  参数值*/参数值

  /init-param

  初始化参数

  param-name CORS . allowsubdomains/param-name

  参数值错误/参数值

  /init-param

  初始化参数

  param-name CORS . supported methods/param-name

  参数值GET,HEAD,POST,OPTIONS/参数值

  /init-param

  初始化参数

  param-name CORS . supported headers/param-name

  参数值接受,来源,X请求,内容类型,最后修改/参数值

  /init-param

  初始化参数

  param-name CORS . exposed header/param-name

  !-您可以在这里添加一些您自己的公开标题-

  参数值X测试1,X测试2/参数值

  /init-param

  初始化参数

  param-name CORS . supports credentials/param-name

  参数值真/参数值

  /init-param

  初始化参数

  param-name CORS . maxage/param-name

  参数值3600/参数值

  /init-param

  /过滤器

  过滤映射

  !- CORS滤波映射-

  过滤器名称CORS/过滤器名称

  url模式/* /url模式

  /filter-映射

  请注意,上面的配置文件应该放在web.xml前面,作为第一个过滤器存在(可以有多个过滤器)。

  第四步:安全模块可能配置错误(注意,有些框架,比如公司的私有框架,是有安全模块的,有时候这些安全模块的配置会影响跨域配置,可以尝试先关闭)

  网络背景配置。NET后台配置可以参考以下步骤:

  步骤1:网站配置

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

  请注意,上面的截图比较老。如果配置仍然出错,您可以考虑添加更多的头权限,例如:

  第二步:其他更多配置。如果第一步后仍有跨域问题,可能是:

  界面中对一些请求类型有限制(比如写死帖等。).请在此时取消限制。

  接口,原点:*重复配置,请删除。

  来源:*在IIS服务器中重复配置,请将其删除。

  用代理解决接口的跨域问题

  请注意,由于接口代理是有价格的,所以这只能在开发过程中进行。

  与前面的方法不同,前面的CORS是后端解决方案,这主要是接口的前端代理,即:

  Ajax前端请求一个本地接口。

  本地接口收到请求后,向实际接口请求数据,然后将信息返回给前端。

  一般node.js可以作为代理使用。

  至于如何实现代理,这里就不重点介绍了。方法很多,也不难。基本上都是基于node.js

  搜索关键字node.js,可以通过代理请求找到大量方案。

  如何分析ajax跨域

  上面已经介绍了跨域的原理以及如何解决,但是在实际的过程中发现还是有很多人无法通过参考类似的文档来解决跨域问题,主要是因为前端人员不知道什么时候产生了跨域问题,什么时候没有,所以下面稍微介绍一下如何分析一个请求是否跨域:

  数据包捕获请求数据

  当然,第一步是了解ajax请求发送和接收了哪些数据。做到这一点并不难,不需要fiddler等工具。它只是基于Chrome。

  Chrome打开ajax对应的页面,F12打开Dev Tools。

  发送ajax请求

  面板-网络- XHR在右边,然后找到刚才的ajax请求并点击它。

  示例1(普通的ajax请求)

  上述要求是正确的要求。为了方便起见,我指出了每个标题字段的含义。我们可以清楚地看到,接口返回的响应头字段包括

  access-Control-Allow-Headers:X-Requested-With,Content-Type,Accept

  访问控制允许方法:Get,Post,Put,OPTIONS

  访问控制允许来源:*

  所以浏览器在收到响应的时候,判断出了正确的请求,自然不会报错,成功获取了响应数据。

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

  为了方便起见,我们还是以上面的错误性能为例。

  在此请求中,接口Allow不包括选项,因此请求出现在跨域中,

  在这个请求中,Access-Control-Allow-Origin: *出现了两次,导致跨域配置不正确,出现错误。

  更多的跨域错误基本都差不多,除了上面三个不满足(Headers,Allow,Origin),这里就不赘述了。

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

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

  例如,这个请求的跨域配置没有问题。它出错只是因为请求的接受与响应的内容类型不匹配。

  更多

  基本上,这是分析ajax请求的方法。你可以通过Chrome了解有哪些数据被发送和接收,然后逐一对比,找出问题所在。

  写下最后的话

  跨领域是一个老生常谈的话题。网上有很多跨领域的资料,也有很多优秀的产品(比如阮一峰前辈)。但是,作为前端人,不应该流于表面,所以才有了这篇文章。

  前路漫漫,望与大家共勉!

  附录

  参考数据

  浏览器同源策略及其规避方法(阮一峰)

  跨域资源共享CORS详解(阮一峰)

  我之前在cnblog上的文章

  https://mp.weixin.qq.com/s?_ _ biz=mzaxode 2 JM 1ma==mid=2651553322 idx=1 sn=5909 BBB 98 BD 44d 286 e 080 e6f 3499 c 860 chksm=8025 a9 ebb 75220 FD 26803 f 740 a 3820 b 07 BD 02 e EBA 35 aaee 09 f 730 e 7 ef 8 af 506 FFB 6 a 433 ace MP share=1 scene=1 Sr

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: