基础-跨域问题与解决方案

跨域问题在日常开发中，嘿，我不说经常遇到了，而是遇不到😌。怎么说呢？你是半路进公司，项目大部分都是到一半了，所以你没遇到跨域。或者项目是你起的，用的vue，稀里糊涂的配个代理，后端把什么权限打开了，你也遇不到跨域。在文件上传，需要转base64，或者店家下砸页面海报时报错了，报错内容是什么origin的，你张口就来是跨域，然后找啊找也不懂怎么办，后端动下代码就OK了，等等等等。所以说，这个问题，要么是不遇到，要么是遇到了不懂解决。在八股文面试中，问跨域的方案，张口就来jsonp或者cors或者proxy，但实际怎么去操作，在vue项目、在react项目或者在原生的网页如何做，都是一头雾水。

那先来看个例子，随便接一个网站的接口，

js 复制代码

  <script>
    fetch('https://pvp.qq.com/web201605/js/herolist.json').then(res=>res.json).then(done=>{
      console.log('done',done);
    })
  </script>

结果就是报错。那下面就慢慢谈谈吧，这涉及到同源策略。

同源策略和跨域问题

同源策略是一套浏览器安全机制 ，当一个源的文档和脚本，与另一个源的资源进行通讯时，同源策略就会对这个通信做出不同程度的限制。

简单来说，同源策略是对同源资源放行，对异源资源限制。因此限制造成的开发问题，称之为跨域（异源）问题。

同源和异源

源(origin) = 协议（schema）+ 域名（domain）+ 端口（port）。

两个Url地址的源完全相同，则称之为同源，否则称之为异源。

跨域出现的场景

跨域可能出现在以下三种场景：

网络通信

a元素的跳转；加载css、js、图片等；AJAX等。
JS API

window.open、window.parent、ifram.contentWindow等等。
存储

WebStorage、IndexedDB等。

对于不同的跨域场景，以及每个场景中的不同跨域方式，同源策略都有不同的限制。我们就谈谈网络通信中AJAX的跨域问题。

网络中的跨域

当浏览器运行页面后，会发现很多的网络请求，例如css、js、图片、Ajax等等。请求页面的源称之为页面源，在该页面中发起的请求称之为目标源。当页面源与目标源一致时，则为同源请求，否则为异源请求（跨域请求）。

浏览器如何限制异源的请求

浏览器出于多方面的考量，制定了非常繁杂的规则来限制各种跨域请求，但总体的原则非常简单：

对标签发出的跨域请求轻微限制
对AJAX发出的跨域请求严厉限制

解决方案

CORS

CORS（Cross-Origin Resource Sharing）是最正统的跨域解决方案，同时也是浏览器推荐的解决方案。

CORS是一套规则，用于帮助浏览器判断是否校验通过。

CORS的基本理念是：

只要服务器明确表示允许，则校验通过
服务器明确拒绝或没有表示，则校验不通过。

所以，使用CORS解决跨域，必须要保证服务器是「自己人」。

请求分类

CORS将请求分为两类：简单请求 和预检请求。

对不同种类的请求它的规则有所区别。

所以要理解CORS，首先要理解它是如何划分请求的。

简单请求

PS: 这个判定非常详细developer.mozilla.org/en-US/docs/...

总结起来只需要满足以下几点就可以了:

请求方法是GET、POST、HEAD之一
头部字段满足CORS安全规范，详见 W3C

浏览器默认自带的头部字段都是满足安全规范的，只要开发者不改动和新增头部，就不会打破此条规则
如果有Content-Type，必须是下列值中的一个
- text/plain
- multipart/form-data
- application/x-www-form-urlencoded

预检请求`(preflight)`

不是简单请求的，就属于预检请求

对简单请求的验证

当是简单请求时，浏览器会把这个源发给服务器，说兄弟你看这个人有点头脑简单，没啥威胁，你看着办，要不就让他过了吧。服务器说我看看，嗯这个人确实头脑简单，我给你发个通行证，你对一下，如果是他就放他进来吧。

通行证：Access-Control-Allow-Origin:源

对预检请求的验证

预检请求时，浏览器发现你这个人偷偷摸摸，贼眉鼠眼，那是不同意电话联系服务器的，直接把你拦在外面。然后亲自到服务器那里去问，说这个人穿着怎么样，举止怎么样，样貌如何，服务器你看给不给过。然后服务器评定，如果通过了，就返回通行证，通行证里包含着那个人的所有信息，如衣服颜色，身高，戴不戴眼镜，还有通行证的有效期。在有效期内，你上了个厕所回来，把眼镜摘掉了，那对不起，虽然还是你，但是信息不满足，不给过！

小细节

关于cookie

默认情况下，ajax的跨域请求并不会附带cookie，这样一来，某些需要权限的操作就无法进行。

不过可以通过简单的配置就可以实现附带cookie
js 复制代码
// xhr
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;
// fetch api
fetch(url, {
 credentials: "include"
})
这样一来，该跨域的ajax请求就是一个附带身份凭证的请求

当一个请求需要附带cookie时，无论它是简单请求，还是预检请求，都会在请求头中添加cookie字段

而服务器响应时，需要明确告知客户端：服务器允许这样的凭据

告知的方式也非常的简单，只需要在响应头中添加：Access-Control-Allow-Credentials: true即可

对于一个附带身份凭证的请求，若服务器没有明确告知，浏览器仍然视为跨域被拒绝。另外要特别注意的是：对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为*。这就是为什么不推荐使用*的原因.
关于跨域获取响应头

在跨域访问时，JS只能拿到一些最基本的响应头，如：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，如果要访问其他头，则需要服务器设置本响应头。

Access-Control-Expose-Headers头让服务器把允许浏览器访问的头放入白名单，例如：
makefile 复制代码
Access-Control-Expose-Headers: authorization, a, b
这样JS就能够访问指定的响应头了

Jsonp

在很久很久以前...并没有CORS方案

没有规则，只要是请求，直接不给通过。那咋搞？用了ajax，你禁我，不好办那就不办了，我就不用ajax了。

js 复制代码

   <script>
      function callback(res){
        console.log('来自服务器的响应：',res);
      }
    </script>

    <script src="http://localhost:9527/jsonp"></script>

既然格式是这样，那我们就可以来封装一个请求函数。

js 复制代码

   /**
       * @description: 请求函数
       * @param {String} url 请求地址
       * @return {*}
       */
      function request(url) {
        return new Promise((resolve) => {
          window.callback = function (res) {
            script.remove()
            resolve(res)
          };

          const script = document.createElement("script")
          script.src = url;
          document.body.appendChild(script);
        });
      }

现在有个小问题，这个callback是全局函数，当多个请求时会造成名字污染，所以配合后端，给每次请求取个相对唯一的名字。

js 复制代码

 function request(url) {
        return new Promise((resolve, reject) => {
          const reName = `_c_${Math.random().toString(32)}_${Date.now()}`;//函数名
            
          window[reName] = function (res) {
            delete window[reName]; //删除属性
            script.remove();
            resolve(res);
          };

          const script = document.createElement("script");
          script.src = `${url}?callback=${reName}`; //将名字传给服务器
          document.body.appendChild(script);
        });
      }

虽然可以解决问题，但JSONP有着明显的缺陷：

仅能使用GET请求
容易产生安全隐患

恶意攻击者可能利用callback=恶意函数的方式实现XSS攻击
容易被非法站点恶意调用

因此，除非是某些特殊的原因，否则永远不应该使用JSONP

代理

CORS和JSONP均要求服务器是「自己人」

那如果不是呢？那就找一个中间人（代理）

js 复制代码

// proxy
app.get('/hero', async (req, res) => {
  const axios = require('axios');
  const resp = await axios.get('https://pvp.qq.com/web201605/js/herolist.json');

  // 使用CORS解决对代理服务器的跨域
  res.header('access-control-allow-origin', '*');
  res.send(resp.data);
});

用自己的服务器去发请求，把请求到的数据再传回浏览器。

如何选择

最重要的，是要保持生产环境和开发环境一致

下面是一张决策图

怎么理解呢？通过下面两张图来看看。

生产环境有跨域 。图片、js、页面等静态资源放到了静态资源服务器，通过a.com去访问静态资源服务器，所以页面源是a.com。另一个是数据服务器，就是我们所说的后端接口了，接的就是这个服务器，所以请求源是b.com。跨域了，所以选择jsonp或者cors。当生产环境定下cors后，开发环境也得跟着使用cors。这种模式似乎不是很常见。所以说，只要用到了cors，那就是后端问题，他不解决就一哭二闹三上吊。

生产环境没有跨域 。我们打包后，会把dist包给运维，运维放到一个文件夹里，手动部署过的应该都知道哈。后端打包后，也把包给运维，运维启动一个服务器。这种情况，浏览器不能直接访问到静态目录或者测试服务器，运维起了个nginx反向代理。浏览器访问时，使用同一个源访问这个nginx，只是path不一样。这时path有个标识，如果是以api开头的，就连到测试服务器。如果没有api开头，那就访问静态资源。

那在开发环境下，我们也有一个开发服务器，用脚手架搭起来的都有，npm run serve启动就是开发服务器。那测试服务器一般在本地起，也有的使用云服务器。这时我们访问页面localhost:8080/index，而数据在http://192.168.0.14。那我们就可以利用dev-server做代理，通通向dev-server发请求，只不过发ajax的时候，拼接api，这时dev-server就可以去向测试服务发请求。

这种模式是不是很熟悉？我们日常的大都是这种哈。

js 复制代码

// 本地联调
 const proxyAPI = 'http://172.16.1.218' 
 const proxyAPI = 'http://192.168.0.14' 
 const proxyAPI = 'http://172.16.1.121'

这就是本地联调接着目标源了，和谁对接就接谁的。然后配置下代理。

js 复制代码

 devServer: {
    proxy: {
      '/api': {
        target: proxyAPI + ':16000',
        changeOrigin: true
      }
    },
  },

发送ajax请求就会把api拼接上，然后访问目标源。

基础-跨域问题与解决方案

同源策略和跨域问题

同源和异源

跨域出现的场景

网络中的跨域

浏览器如何限制异源的请求

解决方案

CORS

请求分类

简单请求

预检请求(preflight)

对简单请求的验证

对预检请求的验证

小细节

Jsonp

代理

如何选择

预检请求`(preflight)`