跨域这两个字就像一块狗皮膏药一样黏在每一个前端开发者身上，无论你在工作上或者面试中无可避免会遇到这个问题。为了应付面试，我每次都随便背几个方案，也不知道为什么要这样干，反正面完就可以扔了，我想工作上也不会用到那么多乱七八糟的方案。到了真正工作，开发环境有webpack-dev-server搞定，上线了服务端的大佬们也会配好，配了什么我不管，反正不会跨域就是了。日子也就这么混过去了，终于有一天，我觉得不能再继续这样混下去了，我一定要彻底搞懂这个东西！于是就有了这篇文章。
1. 要掌握跨域，首先要知道为什么会有跨域这个问题出现
确实，我们这种搬砖工人就是为了混口饭吃嘛，好好的调个接口告诉我跨域了，这种阻碍我们轻松搬砖的事情真恶心！为什么会跨域？是谁在搞事情？为了找到这个问题的始作俑者，请点击浏览器的同源策略(developer.mozilla.org/zh-CN/docs/…)
这么官方的东西真难懂，没关系，至少你知道了，因为浏览器的同源策略导致了跨域，就是浏览器在搞事情。
所以，浏览器为什么要搞事情？就是不想给好日子我们过？对于这样的质问，浏览器甩锅道：“同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。”
这么官方的话术真难懂，没关系，至少你知道了，似乎这是个安全机制。
所以，究竟为什么需要这样的安全机制？这样的安全机制解决了什么问题？别急，让我们继续研究下去。
2. 没有同源策略限制的两大危险场景
据我了解，浏览器是从两个方面去做这个同源策略的，一是针对接口的请求，二是针对Dom的查询。试想一下没有这样的限制上述两种动作有什么危险。
3. 没有同源策略限制的接口请求
有一个小小的东西叫cookie大家应该知道，一般用来处理登录等场景，目的是让服务端知道谁发出的这次请求。如果你请求了接口进行登录，服务端验证通过后会在响应头加入Set-Cookie字段，然后下次再发请求的时候，浏览器会自动将cookie附加在HTTP请求的头字段Cookie中，服务端就能知道这个用户已经登录过了。知道这个之后，我们来看场景：
1. 你准备去清空你的购物车，于是打开了买买买网站www.maimaimai.com，然后登录成功，一看，购物车东西这么少，不行，还得买多点。
2. 你在看有什么东西买的过程中，你的好基友发给你一个链接www.nidongde.com，一脸yin笑地跟你说：“你懂的”，你毫不犹豫打开了。
3. 你饶有兴致地浏览着www.nidongde.com，谁知这个网站暗地里做了些不可描述的事情！由于没有同源策略的限制，它向www.maimaimai.com发起了请求！聪明的你一定想到上面的话“服务端验证通过后会在响应头加入Set-Cookie字段，然后下次再发请求的时候，浏览器会自动将cookie附加在HTTP请求的头字段Cookie中”，这样一来，这个不法网站就相当于登录了你的账号，可以为所欲为了！如果这不是一个买买买账号，而是你的银行账号，那……
这就是传说中的CSRF攻击浅谈CSRF攻击方式。
看了这波CSRF攻击我在想，即使有了同源策略限制，但cookie是明文的，还不是一样能拿下来。于是我看了一些cookie相关的文章聊一聊 cookie、Cookie/Session的机制与安全，知道了服务端可以设置httpOnly，使得前端无法操作cookie，如果没有这样的设置，像XSS攻击就可以去获取到cookieWeb安全测试之XSS；设置secure，则保证在https的加密通信中传输以防截获。
4. 没有同源策略限制的Dom查询
1. 有一天你刚睡醒，收到一封邮件，说是你的银行账号有风险，赶紧点进www.yinghang.com改密码。你吓尿了，赶紧点进去，还是熟悉的银行登录界面，你果断输入你的账号密码，登录进去看看钱有没有少了。
2. 睡眼朦胧的你没看清楚，平时访问的银行网站是www.yinhang.com，而现在访问的是www.yinghang.com，这个钓鱼网站做了什么呢？
// HTML
<iframe name="yinhang" src="www.yinhang.com"></iframe>
// JS
// 由于没有同源策略的限制，钓鱼网站可以直接拿到别的网站的Dom
const iframe = window.frames['yinhang']
const node = iframe.document.getElementById('你输入账号密码的Input')
console.log(`拿到了这个${node}，我还拿不到你刚刚输入的账号密码吗`)
由此我们知道，同源策略确实能规避一些危险，不是说有了同源策略就安全，只是说同源策略是一种浏览器最基本的安全机制，毕竟能提高一点攻击的成本。其实没有刺不穿的盾，只是攻击的成本和攻击成功后获得的利益成不成正比。
以上介绍转自：segmentfault.com/a/119000001…
5. 跨域问题
跨域：浏览器对于javascript的同源策略的限制。那么问题来了，有哪些跨域？
以下情况都属于跨域：
如果域名和端口都相同，但是请求路径不同，不属于跨域，如：
www.jd.com/item
www.jd.com/goods
http和https也属于跨域因为协议不同，也属于跨域
跨域问题示例：从前端页面mng.xx.com发送ajax请求，通过vue-router将请求发送到zull网关api.xx.com，由于ajax请求存在跨域问题，因此发生错误。
跨域不一定都会有跨域问题。
因为跨域问题是浏览器对于ajax请求的一种安全限制：一个页面发起的ajax请求，只能是与当前页域名相同的路径，这能有效的阻止跨站攻击。
因此：跨域问题 是针对ajax的一种限制。但是这却给我们的开发带来了不便，而且在实际生产环境中，肯定会有很多台服务器之间交互，地址和端口都可能不同
- 解决跨域问题的方案
* Jsonp
最早的解决方案，利用script标签可以跨域的原理实现。
限制：
需要服务的支持
只能发起GET请求
简单讲，Jsonp解决跨域问题步骤通常是:
（1）在发送跨域请求的源页面，创建一个js方法methodRequest（para）,要请求的数据参用数para接收
（2）在源页面利用script标签封装要跨域的ajax请求 <script src = "http://127.0.0.1:80/list/cors?id=..."></script>
（3）在要跨域访问的后台，接收请求并处理业务逻辑，将结果以json字符串按约定进行封装，如:
@Getmapping("/list/cors")
@ResponseBody
public String jsonP(HttpServletResponse response, @RequestParam("id") Long id) {
Object res = null;
.....//执行业务逻辑
return "methodRequest(\""+ res +\"");";//约定方法名methodRequest，将请求数据方式方法参数中
}
在前端页面中进行路径为/list/cors?id=的ajax请求时，服务端会返回一个Json字符串，包含约定的方法名和参数，前端页面对约定的方法名进行调用，即可将数据取出。
* nginx反向代理
思路是：利用nginx把跨域反向代理为不跨域，支持各种请求方式
缺点：需要在nginx进行额外配置，语义不清晰
简单讲，就是将要进行跨域的请求，都利用Nginx反向代理到对应的服务器,比如所有来自mng.xx.com的请求/，直接反向代理到9xxx端口(前端服务)，所有经过网关的请求/api，都代理到10xxx网关服务。
【注】要想Nginx反向代理解决跨域，上述配置中，路径“/api”对应的location应该配置在路径“/”前面，否则不起作用
* CORS
规范化的跨域请求解决方案，安全可靠。
优势：在服务端进行控制是否允许跨域，可自定义规则支持各种请求方式
缺点：会产生额外的请求
什么是cors
CORS是一个W3C标准，全称是”跨域资源共享”（Cross-origin resource sharing）。
它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。
CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。
浏览器端：
目前，所有浏览器都支持该功能（IE10以下不行）。整个CORS通信过程，都是浏览器自动完成，不需要用户参与。
服务端：
CORS通信与AJAX没有任何差别，因此不需要改变以前的业务逻辑。只不过，浏览器会在请求中携带一些头信息，需要以此判断是否允许其跨域，然后在响应头中加入一些信息即可。这一般通过过滤器完成即可。
浏览器会将ajax请求分为两类，其处理方案略有差异：简单请求、特殊请求.
简单请求
只要同时满足以下两条件，就属于简单请求：
（1) 请求方法是以下三种方法之一： HEAD GET POST
（2）HTTP的头信息不超出以下几种字段：
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain
当浏览器发现发起的ajax请求是简单请求时，会在请求头中携带一个字段：Origin 其中会指出当前请求属于哪个域（协议+域名+端口）。服务会根据这个值决定是否允许其跨域。如果服务器允许跨域，需要在返回的响应头中携带下面信息：
Access-Control-Allow-Origin: http://mng.xx.com(源域名)
Access-Control-Allow-Credentials: true
Content-Type: text/html; charset=utf-8
Access-Control-Allow-Origin：可接受的域，是一个具体域名或者*（代表任意域名）
Access-Control-Allow-Credentials：是否允许携带cookie，默认情况下，cors不会携带cookie，除非这个值是true
要想操作cookie，需要满足3个条件：
(1)服务的响应头中需要携带Access-Control-Allow-Credentials并且为true。
(2)浏览器发起ajax需要指定withCredentials 为true
(3)响应头中的Access-Control-Allow-Origin一定不能为*，必须是指定的域名
不符合简单请求的条件，会被浏览器判定为特殊请求,，例如请求方式为PUT。特殊请求会在正式通信之前，增加一次HTTP查询请求，称为”预检”请求（preflight）。浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错,总之就是会发两次请求，一次请求确认信息，一次用于发送跨域请求。 “预检”请求的样板：
OPTIONS /cors HTTP/1.1
Origin: http://mng.xx.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.xx.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...
与简单请求相比，除了Origin以外，多了两个头：
- Access-Control-Request-Method：接下来会用到的请求方式，比如PUT
- Access-Control-Request-Headers：会额外用到的头信息
预检请求的响应
服务的收到预检请求，如果许可跨域，会发出响应：
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://mng.xx.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Max-Age: 1728000
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
除了Access-Control-Allow-Origin和Access-Control-Allow-Credentials以外，这里又额外多出3个头：
- Access-Control-Allow-Methods：允许请求的方式
- Access-Control-Allow-Headers：允许携带的头
- Access-Control-Max-Age：本次许可的有效时长，单位是秒，过期之前的ajax请求就无需再次进行预检了
如果浏览器得到上述响应，则认定为可以跨域，后续就跟简单请求的处理相同。
CorsFilter
SpringMVC已经实现了CORS的跨域过滤器：CorsFilter ,内部已经实现了刚才所讲的判定逻辑，可以直接用。
在zull网关服务中编写一个配置类作为全局跨域访问过滤器，并且注册CorsFilterr>
直接请求网关，可以正常路由到对应的微服务，返回对应的Json数据
进行跨域请求时，发生跨域问题：
利用CorsFilter处理后，解决跨域问题：
另外，可以利用注解@CrossOrigin(origins = "xxx") 解决一些跨域问题。
