感谢来自微医大前端技术 公众号提供的Theme模板
编者荐语
本文将为大家介绍，前端开发中，最常用的几种跨域解决方案；
看完本文可以系统地掌握，不同种跨域解决方案间的巧妙，以及它们的用法、原理、局限性和适用的场景
包括以下几个方面：
同源是什么？
如果两个URL的协议、主机名host和端口号port都相同的话，则这两个URL是同源。
同源策略
同源策略是一个重要的安全策略。它能够阻断恶意文档，减少被攻击的媒介。
真实项目中，很少有同源策略，大部分都是非同源策略
跨域是什么？
当协议、域名与端口号中任意一个不相同时，都算作不同域，不同域之间相互请求资源的表现(非同源策略请求)，称作”跨域“。
跨域现象
那么我们就下面的网址分析一下，哪一块是协议，哪一块是域名及端口号
http://kbs.sports.qq.com/index.html
协议：http(还有以一种https协议)
域名：kbs.sports.qq.com
端口号：80
https://127.0.0.1:3000
协议：https
域名：127.0.0.1
端口号：3000
假如我们的真实项目开发中的Web服务器地址为 ”“，而需要请求的数据接口地址为 ""。
当Web服务器的地址向数据接口的地址发送请求时，便会造成了跨域现象
造成跨域的几种常见表现
Web服务器：主要用来静态资源文件的处理
解决方案
在后面会详细分析这四种解决方案的原理和用法配置，以及它们的优点和局限性
注意： 基于ajax或fetch发送请求时，如果是跨域的，则浏览器默认的安全策略会禁止该跨域请求
补充说明：以下所有的测试用例，均由Web：:5500/index.html向API：:1001/list发起请求
API接口的服务器端是自己通过建立的，下文在服务器端以app.use中间件的形式接受来自客户端的请求并做处理。
即 在“:1001/list”from “:55”上对的访问已被CORS策略阻止:被请求的资源上没有“- - allow-”头
在后端开启了一个端口号为1001的服务器之后前端跨域解决方案，我们来实践一下
let xhr = new XMLHttpRequest;
xhr.open('get', 'http://127.0.0.1:1001/list');
xhr.onreadystatechange = () => {
if (xhr.status === 200 && xhr.readyState === 4) {
console.log(xhr.responseText);
}
};
xhr.send();
跨域的常见报错提示
这就是由于浏览器默认的安全策略禁止导致的。
下面介绍一下几种常见的解决方案。
JSONP
原理：JSONP利用标签不存在域的限制，且定义一个全局执行上下文中的函数func
（用来接收服务器端返回的数据信息）来接收数据，从而实现跨域请求。
弊端：
图解JSONP的原理
手动封装JSONP
必须是一个全局上下文中的函数
（防止不是全局的函数，我们需要把这个函数放在全局上，并且从服务器端接收回信息时，要浏览器执行该函数）
注意：
// 客户端
function jsonp(url, callback) {
// 把传递的回调函数挂载到全局上
let uniqueName = `jsonp${new Date().getTime()}`;
// 套了一层 anonymous function
// 目的让 返回的callback执行且删除创建的标签
window[uniqueName] = data => {
// 从服务器获取结果并让浏览器执行callback
document.body.removeChild(script);
delete window[uniqueName];
callback && callback(data);
}
// 处理URL
url += `${url.includes('?')} ? '&' : '?}callback=${uniqueName}'`;
// 发送请求
let script = document.createElement('script');
script.src = url;
document.body.appendChild(script);
}
// 执行第二个参数 callback，获取数据
jsonp('http://127.0.0.1:1001/list?userName="lsh"', (result) => {
console.log(result);
})
// 服务器端
// Api请求数据
app.get('/list', (req, res) => {
// req.query 问号后面传递的参数信息
// 此时的callback 为传递过来的函数名字 (uniqueName)
let { callback } = req.query;
// 准备返回的数据（字符串）
let res = { code: 0, data: [10,20] };
let str = `${callback}($(JSON.stringify(res)))`;
// 返回给客户端数据
res.send(str);
})
测试用例展示：
// 服务器请求的 url
Request URL:
http://127.0.0.1:1001/list?userName="lsh"&callback=jsonp159876002
// 服务器返回的函数callback
jsonp159876002({"code":0, "data": [10,20]});
// 客户端接收的数据信息
{ code: 0, data: Array(2) }
当浏览器发现返回的是({"code":0, "data": [10,20]});这个函数，会自动帮我们执行的。
JSONP弊端
在上文中说到只要服务器端那里设置了允许通过jsonp的形式跨域请求，我们就可以取回数据。
下面是在我们封装完jsonp方法之后，向一个允许任何源向该服务器发送请求的网址xxx
jsonp('https://matchweb.sports.qq.com/matchUnion/cateColumns?from=pc', result => {
console.log(result);
});
CORS
上文提到，不允许跨域的根本原因是因为--Allow-已被禁止
那么只要让服务器端设置允许源就可以了
原理：解决掉浏览器的默认安全策略，在服务器端设置允许哪些源请求就可以了
先来看一下下面的设置有哪些问题
// 服务器端
app.use((req, res, next) => {
// * 允许所有源（不安全/不能携带资源凭证）
res.header("Access-Control-Allow-Origin", "*");
res.header("Access-Control-Allow-Credentials", true);
/* res.header("Access-Control-Allow-Headers", "Content-Type,....");
res.header("Access-Control-Allow-Methods", "GET,..."); */
// 试探请求：在CORS跨域请求中，首先浏览器会自己发送一个试探请求，验证是否可以和服务器跨域通信，服务器返回200，则浏览器继续发送真实的请求
req.method === 'OPTIONS' ? res.send('CURRENT SERVICES SUPPORT CROSS DOMAIN REQUESTS!') : next();
});
// 客户端
let xhr = new XMLHttpRequest;
xhr.open('get', 'http://127.0.0.1:1001/list');
xhr.setRequestHeader('Cookie', 'name=jason');
xhr.withCredentials = true;
xhr.onreadystatechange = () => {
if (xhr.status === 200 && xhr.readyState === 4) {
console.log(xhr.responseText);
}
};
xhr.send();
当我们一旦在服务器端设置了允许任何源可以请求之后，其实请求是不安全的，并且要求客户端不能携带资源凭证（比如上文中的字段），浏览器端会报错。
告诉我们字段是不安全的也不能被设置的，如果允许源为'*'的话也是不允许的。
假如在我们的真实项目开发中
正确写法✅
app.use((req, res, next) => {
// 也可自定义白名单，检验请求的源是否在白名单里，动态设置
/* let safeList = [
"http://127.0.0.1:5500",
xxx,
xxxxx,
]; */
res.header("Access-Control-Allow-Origin", "http://127.0.0.1:5500");
res.header("Access-Control-Allow-Credentials", true); // 设置是否可携带资源凭证
/* res.header("Access-Control-Allow-Headers", "Content-Type,....");
res.header("Access-Control-Allow-Methods", "GET,..."); */
// 试探请求：在CORS跨域请求中，首先浏览器会自己发送一个试探请求，验证是否可以和服务器跨域通信，服务器返回200，则浏览器继续发送真实的请求
req.method === 'OPTIONS' ? res.send('CURRENT SERVICES SUPPORT CROSS DOMAIN REQUESTS!') : next();
});
CORS的好处CORS的局限性Proxy
Proxy翻译为“代理”，是由配置的一个插件，叫"-dev-"（只能在开发环境中使用）
Proxy在中的配置
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
mode: 'production',
entry: './src/main.js',
output: {...},
devServer: {
port: '3000',
compress: true,
open: true,
hot: true,
proxy: {
'/': {
target: 'http://127.0.0.1:3001',
changeOrigin: true
}
}
},
// 配置WEBPACK的插件
plugins: [
new HtmlWebpackPlugin({
template: `./public/index.html`,
filename: `index.html`
})
]
};
图解Proxy的原理
Proxy代理其实相当于由-dev-配置在本地创建了一个port=3000的服务，利用node的中间层代理（分发）解决了浏览器的同源策略限制。
但是它只能在开发环境下使用，因为dev-只是一个的一个插件；
如果需要在生产环境下使用，需要我们配置Nginx反向代理服务器；
另外如果是自己实现node服务层代理：无论是开发环境还是生产环境都可以处理（node中间层和客户端是同源，中间层帮助我们向服务器请求数据，再把数据返回给客户端）
Proxy的局限性
只能在本地开发阶段使用
配置Nginx反向代理
主要作为生产环境下跨域的解决方案。
原理：利用Node中间层的分发机制，将请求的URL转向服务器端的地址
配置反向代理
server {
listen: 80;
server_name: 192.168.161.189;
loaction: {
proxy_pass_http://127.0.0.1:1001; // 请求转向这个URL地址，服务器地址
root html;
index index.html;
}
}
简单写了一下伪代码前端跨域解决方案，实际开发中根据需求来配。
POST
假设现在有两个页面，分别为A页面port=1001、B页面port=1002，实现页面A与页面B的页面通信（跨域）
原理：
主要利用内置的和传递信息和接收信息。
A.html
// 把 B页面当做A的子页面嵌入到A页面里
<iframe id="iframe" src="http://127.0.0.1:1002/B.html" frameborder="0" style="display: none;"></iframe>
<script>
iframe.onload = function () {
iframe.contentWindow.postMessage('珠峰培训', 'http://127.0.0.1:1002/');
}
//=>监听B传递的信息
window.onmessage = function (ev) {
console.log(ev.data);
}
</script>
B.html
//=>监听A发送过来的信息
window.onmessage = function (ev) {
// console.log(ev.data);
//=>ev.source:A
ev.source.postMessage(ev.data + '@@@', '*');
}
</script>
几种方案的比较
1. JSONP方案需要前后端共同配置完成（利用标签不存在域的限制）【麻烦，老项目使用】
2. CORS原理简单，但只能配置单一源，如果需要配置多个源，也只能从白名单中筛选出某一个符合表求的【偶尔使用】
服务器端需要单独做处理，客户端较为简单
3. Proxy客户端通过dev-，生产环境需要配置Nginx反向代理（利用Node中间层分发机制）【常用】
感谢大家
如果你觉得这篇内容对你挺有启发，我想邀请你帮我三个小忙：
点个「在看」，让更多的人也能看到这篇内容（喜欢不点在看，都是耍流氓 -_-）
欢迎加我微信「」一起交流学习...
关注公众号「前端时光屋」，持续为你推送精选好文。