Ajax 跨域问题及其解决方案

Posted 2023-03-24

参考技术A

主流的 前后端分离模式 下，当前端调用后台接口时，由于是在非同一个域下的请求，从而会引发 浏览器 的自我安全保护机制，最终结果是 接口成功请求并响应 ，但 前端不能正常处理该返回数据 。

因此，当 同时满足 以下三个条件的情况下，就会出现跨域问题：

想要彻底解决跨域问题，只需要破坏以上三个条件的任一即可：

添加浏览器启动参数： chrome --disable-web-security ，但是极不推荐这种解决方式。

Jsonp，全称 JSON with Padding ，一种非官方的协议，而是一种约定；前端通过向后台发送 script 类型请求解决跨域，此时接口响应的 application/javascript 类型的数据会作为 callback 函数的参数进行处理。

所以，后台也需要做相应的处理。以 Java 为例，添加如下配置即可：

综上， jsonp 请求存在以下几个弊端：

用 nginx 或 Apache 来代理调用方的请求（ 客户端变更为相对路径请求，而非绝对路径 ），此时对于浏览器来说，由于请求是同源的，因此就不存在跨域问题。

以 Java 应用为例，添加如下全局配置：

如果只想针对某个类下的接口，或者是某个具体的接口配置允许跨域，只需要在相应的地方添加注解 @CrossOrigin 即可。

如果配置了 nginx 作为代理服务器，那么只需要为 nginx 添加支持跨域请求即可：

Q1：浏览器在执行跨域请求时，是先执行后判断，还是先判断后执行？
A1：都有可能，这需要根据所发送的请求是 简单请求 还是 非简单请求 来判断；如果是非简单请求，浏览器每次在执行真正的请求之前，还会先发送一个 options 请求方式的预检命令【 可设定缓存时长，取消每次请求都要预检，提高效率，参考上面的服务端配置 】。关于两种请求的区分及定义，参考下图说明：

Q2：如果是允许带（ 被调用方 ） cookie 的跨域请求，此时服务端同样配置为 Access-Control-Allow-Origin 等于 * ，前端是否还可以请求成功？
A2：不可以，此时要将 Access-Control-Allow-Origin 指定为 调用方 具体的域【 可以先取得调用方的域再动态配置，这样就不存在多个域请求的限制问题 】，并且添加配置 Access-Control-Allow-Credentials 为 true 。

浏览器跨域及其解决方案

参考技术A

title: 浏览器跨域及其解决方案
author: May
date: 20220428</pre>

什么是跨域跨域的表现解决跨域问题- 浏览器设置(不推荐)- 前端的非正统解决方式- CORS(跨域资源共享)- 配置nginx反向代理

跨域 出于浏览器的同源策略限制， 同源 是指协议、域名、端口都一样， 同源策略（Sameoriginpolicy） 是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。

调用页面时接口数据不返回，控制台中会有红色的报错信息中有类似于 CORS policy 关键字。另外，在最新谷歌浏览器中，会有提出类似于loaded over HTTPS此种关键字，均可以考虑为跨域导致。

[图片上传失败...(image-26deed-1651135597111)]

tips: 有的时候后台小伙伴使用postman测试好的接口，前端不可以使用，原因就是postman不是浏览器，不会有同源限制，同理移动设备app开发和小程序开发也不会有这个问题。这个不是前端bug，同源限制也不是一个不好的规则。

虽然跨域不是一个不好的事情，但是对于前后端分离的web开发来说确实需要解决的，大致的解决方案可分为：

直接从根源解决问题，让浏览器安全策略不起作用。这个方法虽然可以解决问题但是不现实。

官方正统解决方案， CORS规范 允许服务器向浏览器返回一些HTTP Headers，浏览器可以基于这些HTTP Headers来决定是否突破SOP的限制。需要后端配合，浏览器需要什么，接口服务给什么。

nginx是一个高性能的HTTP和反向代理web服务器，nginx用来解决跨域问题的原理与 前端非正统解决方式 的 proxy 的思路是一致的。项目请求接口由nginx服务发出，获取到的数据再经由nginx传递给前端项目，这样前端的请求其实都是由nginx处理的，就没有跨域发生了。