记一次接口跨域的踩坑之旅-[七日打卡6]

一、前言

众所周知在前端开发过程中和服务端接口进行http请求通讯的过程中，不可避免的会出现跨域的情况。在这么多年的工作当中，遇到过无数多次接口跨域问题，也解决过无数多次跨域问题。概括来说，根据不同场景不同情况，有的是通过前端手段来解决，有的是通过后端手段来解决。

在谈跨域话题之前不得不提的一个前置知识点就是「同源策略」—— same-origin polcy。同源策略的目的是浏览器厂商为了保护用户的信息安全而设立的。这里要注意：只有在浏览器(或webview)的上下文中，并且使用xhr或fetch发起的ajax请求才会有跨域的限制，使用原生native或者如postman等客户端App发起的http请求是不会有跨域的限制。

当然还有跨域读写cookie/Localstorage和跨域操作DOM都是会被同源策略限制的，由于不在本文的讨论范文之内，因此不做过多解释。

二、具体分析

1. 开发阶段跨域

在开发阶段调用服务端接口遇到跨域时，常用的做法可以是使用代理proxy的方式进行处理。

例如

• webpack-dev-server中的proxy选项

proxy: {
  '/api/v1/': {
    target: 'https://another.url.com',
    changeOrigin: true,
  },
},

• github.com/chimurai/ht…

原理就是通过中间的代理进行http请求，而不是直接通过浏览器进行，从而绕过跨域的限制。

此外还有jsonp、charles代理等技术在某些场景下也是可以使用的，工作这么多年下来，使用频率不是很高，但是这些知识点还是要知道的。

如果还有遗漏的技能点，请各位老铁在评论区留言。?

2. 生产环境跨域

跨域资源共享CORS（Cross-Origin Resource Sharing）机制的本质是一系列传输的HTTP头信息，这些HTTP头决定浏览器是否阻止ajax请求的响应。

在服务端配置Response Header的报文头，常见的有配置：

Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: *

一般情况这么配就OK了。

但是又一次遇到一个诡异的问题，同一个接口在chrome浏览器中是正常调用的，但是在Safari浏览器中就提示跨域，提示如图。

在发送options请求预检的过程中配拦截了，提示请求头字段Content-Type不被允许，关键是chrome中是正常的，看起来是在处理这个特殊场景时Safari和chrome的逻辑不一样导致的。

仔细分析对比返回的报文，发现Response Header中还有一个额外的字段：Access-Control-Allow-Headers: *，隐隐感觉就是这个星号有问题。已查资料发现还真是这样。

根据链接中的浏览器兼容性表格显示，*确实在Safari浏览器中不支持。? 你说是不是坑？

解决办法就是把上面那个改成Access-Control-Allow-Headers: Content-Type把值单独列出来，不要用星号。

三、参考资料

1. www.ruanyifeng.com/blog/2016/0…

2. developer.mozilla.org/zh-CN/docs/…

3. stackoverflow.com/questions/6…