cross-domain
什么是跨域请求
简单来说,当一台服务器资源从另一台服务器(不同的域名或者端口)请求一个资源时,就会发起一个跨域 HTTP 请求。
举个简单的例子,http://example-a.com/index.html 这个 HTML 页面请求了 http://example-b.com/resource/image.jpg 这个图片资源时(发起 Ajax 请求,非 标签),就是发起了一个跨域请求。
在不做任何处理的情况下,这个跨域请求是无法被成功请求的,因为浏览器基于同源策略会对跨域请求做一定的限制

浏览器同源策略
浏览器的同源策略(Same-origin policy),同源策略限制了从同一个源加载的文档或者脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制
同源需要同时满足三个条件:
协议(例如同为http协议)
域名(例如同为www.example.com)
端口(例如同为80端口)
如果不同时满足这上面三个条件,那就不符合浏览器的同源策略
必须是域名完全相同,比如说blog.example.com和mail.example.com这两个域名,虽然它们的顶级域名和二级域名(均为 example.com)都相同,但是三级域名(blog 和 mail)不相同,所以也不能算作域名相同
修改域名只能往上修改
例外
下面两种交互就不会触发同源策略:
跨域写操作(Cross-origin writes),例如超链接、重定向以及表单的提交操作,特定少数的
HTTP请求需要添加预检请求(preflight)跨域资源嵌入(Cross-origin embedding)
<script>标签嵌入的跨域脚本,可以使用 CDN,CDN 基本都是其他域的链接,还可以实现JSONP<link>标签嵌入的 CSS 文件,可以使用 CDN,CDN 基本都是其他域的链接<img>标签嵌入图片,可以做打点统计,因为统计方并不一定是同域的,除了能跨域之外,<img>几乎没有浏览器兼容问题,它是一个非常古老的标签<video>和<audio>标签嵌入多媒体资源<object>,<embed>,<applet>的插件@font-face引入的字体,一些浏览器允许跨域字体(cross-origin fonts),一些需要同源字体(same-origin fonts)<frame>和<iframe>载入的任何资源,站点可以使用 X-Frame-Options 消息头来组织这种形式的跨域交互
如果浏览器缺失同源策略这种安全机制会怎么样呢?设想一下,当你登陆了
www.bank.com银行网站进行操作时,浏览器保存了你登录时的Cookie信息,如果没有同源策略,在访问其他网站时,其他网站就可以读取还未过期的Cookie信息,从而伪造登陆进行操作,造成财产损失
同源页面通信方式
==CORS(Cross-origin resource sharing,跨域资源共享)==
常见的方法有四种:
JSONP (script、img、link)
CORS(Cross-origin resource sharing,跨域资源共享)
<iframe>postMessage
document.domain
window.name
location.hash
web socket(双通)
代理服务器(webpack、Nginx)
postMessage和iframe本质上是利用浏览器同源策略的漏洞来进行跨域请求,不是推荐的做法,只能作为低版本浏览器的缓兵之计代理服务器的做法是让浏览器访问同源服务器,再由同源服务器去访问目标服务器,这样虽然可以避免跨域请求的问题,但是原本只需要一次的请求被请求了两次,无疑增加了时间的开销
什么是 CORS
CORS 其实是浏览器制定的一个规范,它的实现则主要在服务端,它通过一些HTTP Header来限制可以访问的域,例如页面A需要访问B服务器上的数据,如果B服务器上声明了允许A的域名访问,那么从A到B的跨域请求就可以完成
对于那些会对服务器数据产生副作用的HTTP请求,浏览器会使用OPTIONS方法发起一个预检请求(preflight request),从而可以获知服务器端是否允许该跨域请求,服务器端确认允许后,才会发起实际的请求。在预检请求的返回中,服务器端也可以告知客户端是否需要身份认证信息
简单请求(Simple requests)
GET, HEAD, POST 方法之一
Header不带自定义的请求头
Content-Type以下三者之一
text/plain
multipart/form-data
application / x-www-form-urlencoded
。。。
举例请求报文: 
响应报文: 
在请求报文中,
Origin字段表明该请求来源于在响应报文中,
Access-Control-Allow-Origin字段被设置为*,表明该资源可以被任意的域访问,若服务端仅允许来自 http://foo.example 域的访问Access-Control-Allow-Origin: http://foo.example
负责请求
预检请求(Preflight Request)
和简单请求不同,「需预检的请求」要求必须先使用 OPTIONS 方法发送一个预检请求到服务器,以获知服务器是否允许该请求,或者是否需要携带身份认证信息。「预检请求」的使用,可以避免跨域请求对服务器的用户数据产生未预期的影响
满足以下条件任一条件时,该请求需要首先发送预检请求
使用了下面任一
HTTP方法:PUT、DELETE、CONNECT、OPTIONS、TRACE、PATCHHeader中设置了自定义请求头
Content-Type 的值不属于以上三者之一
。。。
OPTIONS 请求报文:Access-Control-Request-Method和Access-Control-Request-Headers是浏览器自动加的 
OPTIONS 响应报文: 
预检请求完成之后,再发送实际的请求
OPTIONS预检的优化
Access-Control-Max-Age
这个头部加上后,可以缓存此次请求的秒数,在这个时间范围内,所有同类型的请求都将不再发送预检请求而是直接使用此次返回的头作为判断依据
服务器端实现
Node.js后台配置(express)
JAVA后台配置
获取依赖jar包 (下载 cors-filter-1.7.jar, java-property-utils-1.9.jar 这两个库文件放到lib目录下。(放到对应项目的webContent/WEB-INF/lib/下))
如果项目用了Maven构建的,添加如下依赖到pom.xml中:(非maven请忽视)
添加CORS配置到项目的web.xml中( App/WEB-INF/web.xml)
可能的安全模块配置错误(注意,某些框架中-譬如公司私人框架,有安全模块的,有时候这些安全模块配置会影响跨域配置,这时候可以先尝试关闭它们)
JAVA Spring Boot配置
其他跨域解决方案

==JSONP==(只支持GET、XSS攻击)
客户端代码
服务端Node.js为例:(服务端对应的接口在返回参数外面添加函数包裹层)
postMessage
iframe嵌套页面跨域通信
页面和其打开的新窗口的通信
多窗口之间消息传递
window.postMessage(data,origin)
data:需要传递的数据,html5规范支持任意基本类型或可复制的对象,但部分浏览器只支持字符串,所以传参时最好用JSON.stringify()序列化
origin:协议+主机+端口号,也可以设置为"*",表示可以传递给任意窗口,如果要指定和当前窗口同源的话设置为"/"
chrome打印信息 
成功获取非同源数据,将非同源地址嵌入获取数据页面窗口
window.name
在客户端浏览器中每个页面都有一个独立的窗口对象window,默认情况下window.name为空,在窗口的生命周期中,载入的所有页面共享一个window.name并且每个页面都有对此读写的权限,window.name会一直存在当前窗口,但存储的字符串不超过2M
chrome打印信息 
上面是以window.location跳转的方式获取window.name字符串信息,平时开发中经常需要异步获取
chrome打印信息
成功获取非同源地址的数据信息,主要是通过iframe的src属性,类似含有src属性的标签都可以成功处理跨域问题img,script
location.hash
路径后面的hash可以用来通信
目的a访问c
a给c传个hash,c收到hash后,c把新的ash传递给b,b将结果放到a的hash中
window.parent.parent.location.hash
document.domain
这种方式只适合主域名相同,但子域名不同的iframe跨域 实现原理:两个页面都通过js强制设置document.domain为基础主域,就实现了同域。
Web Socket
nginx代理跨域
配置之后就不需要前端做什么修改了,一般我们在前后端分离项目中开发阶段会采用这种方式,但不是所有场景都能这样做,例如后端接口是一个公共的API,比如一些公共服务获取天气什么的
常见跨域问题

后端允许OPTIONS请求

后台方法允许OPTIONS请求,但是一些配置文件中(如安全配置),阻止了OPTIONS请求,后端关闭对应安全配置

后端增加对应的头部支持

响应头重复
Last updated