所谓同源(即指在同一个域)就是两个页面具有相同的协议(protocol),主机(host)端口号(port)
同源策略是浏览器的一个安全功能,不同源的客户端脚本在没有明确授权的情况下,不能读写对方资源。 同源策略是浏览器安全的基石
同源策略会阻止一个域的 javascript 脚本和另外一个域的内容进行交互。例如办公内外网环境,当我们访问外网一个恶意网站的时候,恶意网站就会利用我们的主机向内网的 url 发送 ajax 请求,破坏或盗取数据
一、浏览器的非同源限制以及3种解决思路
非同源限制
- 无法读取非同源网页的 Cookie、LocalStorage 和 IndexedDB
- 无法接触非同源网页的 DOM
- 无法向非同源地址发送 AJAX 请求,即 XHR 请求
跨域的解决思路 1 —— 避免非同源限制
- 让浏览器不做限制,指定参数,让浏览器不做校验,但该方法不太合理,因为它需要每个人都去做改动
- 不要发出 XHR 请求,这样就算是跨域,浏览器也不会有非同源限制,解决方案是 JSONP,通过动态创建一个 script,通过 script 发出请求
跨域的解决思路 2 —— 跨源资源共享方案
- 根据 W3C 的跨源资源共享方案,在被调用方修改代码,加上字段,告诉浏览器该网站支持跨域
跨域的解决思路 3 —— 隐藏跨域
- 使用 Nginx 反向代理,在 a 域名里面的的请求地址使用反向代理指向 b 域名,让浏览器以为一直在访问 a 网站,不触发跨域限制
二、JSONP
- 普通请求值 XHR,希望得到服务端返回的 content-type 一般是 json
- JSONP 发出的是 script 请求,希望得到的返回是 js 脚本
Content-Type 是指 http/https 发送信息至服务端时的内容编码类型,在 HTTP 协议消息头中,使用 Content-Type 来表示请求和响应中的媒体类型信息。它用来告诉服务端如何处理请求的数据,以及告诉客户端(一般是浏览器)如何解析响应的数据,比如显示图片,解析并展示 html 等等。
并不是请求或响应独有的参数
a JSONP 原理
以 JQuery 为例,发送 ajax 请求的时候,设置dataType:"jsonp"
,将使用 JSONP 方式调用函数,函数的 url 变为myurl?callback=e5bbttt
的形式,e5bbttt 就是一个临时方法名,后端会根据callback
的值返回一个 js 脚本,如
<script>
e5bbttt({"a":"aaa","b":"bbb"});
</script>
JQuery 会提前根据 ajax 中 success 的内容生成一个临时函数,名字就是 xxx
$.ajax({
// 其他省略
dataType:"jsonp",
success:function(data){
console.log(data.a);
console.log(data.b);
},
jsonp:"e5bbttt"
})
// JQuery 生成的临时函数
function e5bbttt(data){
ajaxObject.success(data);
}
服务端返回给客户端的e5bbttt({"a":"aaa","b":"bbb"});
,相当于调用立即(?)调用了 JQuery 生成的e5bbttt
函数,用完这个函数就销毁了(?)
JSONP 也算是一个约定俗成的“协议”,callback 是约定俗成的作为定义临时函数名的参数。如果想自定义这个参数名,需要在 ajax 中用 jsonp 属性定义。
b JSONP 的弊端
- 需要服务器改动代码
- 只支持 GET 请求
- 发送的不是 xhr 请求
- 不安全
三、后端解决跨域
跟用户数据有关的就是动态请求,没有数据的是静态请求,比如 css js,so,HTTP 服务器(Apache、Nginx 等)至少做了两个作用
- HTTP 服务器,处理静态请求
- 反向代理,负载均衡
在服务器端解决跨域有2种解决思路
- 在被调用后端应用解决:在响应头增加指定字段,告诉浏览器允许调用。这种解决方案的请求是直接从浏览器发送给后端服务器,在浏览器上会看到 b.com 的 url
- 在前端服务器解决:这是隐藏跨域的解决方案。这种跨域请求不是直接从浏览器发送的,而是从中间的 http 服务器(前端应用所在服务器)转发过去的,在浏览器中看到的还是 a.com 的 url,所以不会认为是跨域。但是该到 b.com 的请求还是会到 b.com
a 跨域原理及后端解决思路
依据浏览器同源策略,非同源脚本不可操作其他源下面的对象。想要操作其他源下的对象就需要跨域。综上所述,在同源策略的限制下,非同源的网站之间不能发送 ajax 请求。如有需要,可通过降域或其他技术实现。
为了解决浏览器跨域问题,W3C 提出了跨源资源共享方案,即 CORS(Cross-Origin Resource Sharing)。
CORS 可以在不破坏即有规则的情况下,通过后端服务器实现 CORS 接口,就可以实现跨域通信。
CORS 将请求分为两类:简单请求和非简单请求,分别对跨域通信提供了支持。
1 简单请求
- 在 CORS 出现前,发送 HTTP 请求时在头信息中不能包含任何自定义字段,且 HTTP 头信息不超过以下几个字段:
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type 仅为这3种
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain
- 请求方法是 GET HEAD POST 且满足条件1
一个简单请求:
GET /test HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, sdch, br
Origin: http://www.test.com
Host: www.test.com
对于简单请求,CORS 的策略是请求时在请求头中增加一个 Origin 字段,表示请求发出的域。服务器收到请求后,根据该字段判断是否允许该请求访问。
- 如果允许,则在 HTTP 头信息中添加 Access-Control-Allow-Origin 字段,并返回正确的结果
- 如果不允许,则不添加 Access-Control-Allow-Origin 字段
除了上面提到的 Access-Control-Allow-Origin,还有几个字段用于描述 CORS 返回结果
- Access-Control-Allow-Credentials:可选,用户是否可以发送、处理cookie
- Access-Control-Expose-Headers:可选,可以让用户拿到的字段。有几个字段无论是否允许跨域都可以拿到的:Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma
2 非简单请求
一般是发送 JSON 格式的 ajax 请求,或带有自定义头的请求
对于非简单请求的跨源请求,浏览器会在真实请求发出前,增加一次 OPTION 请求,称为预检请求(preflightrequest)。预检请求将真实请求的信息,包括请求方法、自定义头字段、源信息添加到 HTTP 头信息字段中,询问服务器是否允许这样的操作
例如一个 GET 请求的预检请求,包含一个自定义参数 X-Custom-Header
OPTIONS /test HTTP/1.1
Origin: http://www.test.com
Access-Control-Request-Method: GET // 请求使用的 HTTP 方法
Access-Control-Request-Headers: X-Custom-Header // 请求中包含的自定义头字段
Host: www.test.com
服务器收到请求时,需要分别对 Origin、Access-Control-Request-Method、Access-Control-Request-Headers 进行验证,验证通过后,会在返回 HTTP 头信息中添加:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.test.com // 允许的域
Access-Control-Allow-Methods: GET, POST, PUT, DELETE // 允许的方法
Access-Control-Allow-Headers: X-Custom-Header // 允许的自定义字段
Access-Control-Allow-Credentials: true // 是否允许用户发送、处理 cookie
Access-Control-Max-Age: 172800 // 预检请求的有效期,单位为秒。有效期内,不需要发送预检请求,ps 48小时
当预检请求通过后,浏览器才会发送真实请求到服务器。这样就实现了跨域资源的请求访问。
所以后端处理其实处理的就是这次预检请求
==注意:==
==在 Chrome 和 Firefox 中,如果 Access-Control-Allow-Methods 中并未允许 GET/POST/HEAD 请求,但允许跨域了,浏览器还是会允许 GET/POST/HEAD 这些简单请求访问,这时就必须在后台用其他办法禁掉这些 Method==
b 后端应用处理 - Filter&HttpServletResponse 方法
这种方法不会用到 Spring,对 Servlet 也可以使用
在 web.xml 中配置
<!-- 跨域 -->
<filter>
<filter-name>webFliter</filter-name>
<filter-class>com.n031.filter.WebFliter</filter-class>
</filter>
<filter-mapping>
<filter-name>webFliter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
编写 java 类
import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
public class WebFliter implements Filter {
@Override
public void init(FilterConfig filterConfig) throws ServletException {
}
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest)request;
HttpServletResponse res = (HttpServletResponse) response;
// 允许跨域的域名,设置*表示允许所有域名
String origin = req.getHeader("Origin");
if ("abcdefg".contains(origin)) { // 满足指定的条件
res.addHeader("Access-Control-Allow-Origin", origin);
}
res.addHeader("Access-Control-Allow-Origin", "http://www.test.com");
// 允许跨域的方法,可设置*表示所有
res.addHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
// 允许的自定义字段
String headers = req.getHeader("Access-Control-Request-Headers"); // 获取 request 发来的自定义字段
res.addHeader("Access-Control-Allow-Headers", headers);
// 或者
// res.addHeader("Access-Control-Allow-Headers", "X-Custom-Header");
// 预检请求的有效期,单位为秒。有效期内,不需要发送预检请求,ps 48小时
res.addHeader("Access-Control-Max-Age", "172800");
// 还可以有其他配置...
chain.doFilter(request, response);
}
@Override
public void destroy() {
}
}
c 后端应用处理 - Spring 方法
Spring 解决跨域的方法很多,感觉就和茴字有五种写法一样。这里列举的并不全。
先看下原理。说实话虽然搞不懂为什么这么做,但看了下这个类的源码确实是这么写的。
本质都是构造CorsConfiguration
然后委托给DefaultCorsProcessor
实现(责任链模式,要学的东西好多啊...)
public class CorsConfiguration {
private List<String> allowedOrigins;
private List<String> allowedMethods;
private List<String> allowedHeaders;
private List<String> exposedHeaders;
private Boolean allowCredentials;
private Long maxAge;
}
DefaultCorsProcessor
的processRequest
处理步骤如下(spring-web 5.1.8-RELEASE
)
- 判断是否是包含 Origin 字段,不包含就放行,否则继续判断
- 判断 Response 的 Header 是否已经包含 Access-Control-Allow-Origin。如果包含,证明已经被处理过了,放行,否则继续判断
- 判断是否同源,如果是则放行,否则继续判断
- 到此步基本已经得出这是个跨域请求的结论。然后看配置了 CORS 规则
- 没有配置,且是预检请求,则拒绝该请求(说明该应用禁止跨域)
- 没有配置,且不是预检请求,跳过跨域处理(有可能导致返回数据被浏览器拦截)
- 配置了,则根据配置的规则(
CorsConfiguration
)决定是否放行
1 在 Controller 上添加 @CrossOrigin 注解
这种方式适合只有一两个 rest 接口需要跨域或者没有网关的情况下,这种处理方式就非常简单,适合在原来基代码基础上修改,影响比较小。
@CrossOrigin(allowCredentials = "true", allowedHeaders = "*", methods = {RequestMethod.GET, RequestMethod.POST, RequestMethod.DELETE}, origins = "*")
@PostMapping("/abc")
public String handler(@RequestBody String json) {
return "abc";
}
2 增加 WebMvcConfigurer 全局配置
@Configuration
public class CorsConfig extends WebMvcConfigurerAdapter {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")// 允许跨域的访问路径
.allowedOrigins("*")// 允许跨域访问的源
.allowedMethods("POST", "GET", "PUT", "OPTIONS", "DELETE")// 允许请求方法
.maxAge(172800)// 预检间隔时间
.allowCredentials(true);// 是否允许发送 cookie
}
}
注意由于 Java8 开始支持 default method,这个类从 spring 5.0 开始已经过期,未来这个方法将转移到WebMvcConfigurer
接口中
default void addCorsMappings(CorsRegistry registry){}
3 结合 Filter 使用
其实和方法2类似,都是构造CorsConfiguration
@Configuration
public class CorsConfig {
@Bean
public FilterRegistrationBean<CorsFilter> corsFilter() {
UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
CorsConfiguration config = new CorsConfiguration();
// 是否发送cookie
config.setAllowCredentials(true);
// 允许的网站域名,全允许则设为 *
config.addAllowedOrigin("http://localhost:8088");
// 允许 HEADER 或 METHOD , * 为全部
config.addAllowedHeader("*");
config.addAllowedMethod("*");
source.registerCorsConfiguration("/**", config);
FilterRegistrationBean<CorsFilter> bean = new FilterRegistrationBean<>(new CorsFilter(source));
// 这个顺序很重要,为避免麻烦请设置在最前
bean.setOrder(0);
return bean;
}
}
以上这种方案如果微服务多的话,需要在每个服务的主类上都加上这么段代码,增加了维护量。
这三种方案都是在 SpringBoot 的基础上实现的解决方案,在模块较多或者接口较多的情况下不易维护。
既然 Spring Cloud 自带 Gateway,下面就讲讲使用 Gateway 的跨域解决方案。(Gateway 是取代不断跳票的 Zuul 的新一代网关)
4 在 Gateway 增加 CorsFilter 拦截器
==4 5 方法未验证==
这种方案跟方案三有些类似,只不过是放到了 Gateway 端,对于有多个微服务模块的情况下,就大大减少了 SpringBoot 模块端的代码量,让各个模块更集中精力做业务逻辑实现。这个方案只需要在 Gateway 里添加 Filter 代码类即可。
import org.springframework.context.annotation.Configuration;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpMethod;
import org.springframework.http.HttpStatus;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.http.server.reactive.ServerHttpResponse;
import org.springframework.web.cors.CorsUtils;
import org.springframework.web.server.ServerWebExchange;
import org.springframework.web.server.WebFilter;
import org.springframework.web.server.WebFilterChain;
import reactor.core.publisher.Mono;
import javax.servlet.http.HttpServletRequest;
@Configuration
public class CorsWebFilter implements WebFilter {
private static final String ALL = "*";
private static final String MAX_AGE = "18000";
@Override
public Mono<Void> filter(ServerWebExchange ctx, WebFilterChain chain) {
ServerHttpRequest request = ctx.getRequest();
String path = request.getPath().value();
ServerHttpResponse response = ctx.getResponse();
if ("/favicon.ico".equals(path)) {
response.setStatusCode(HttpStatus.OK);
return Mono.empty();
}
if (!CorsUtils.isCorsRequest((HttpServletRequest) request)) {
return chain.filter(ctx);
}
HttpHeaders requestHeaders = request.getHeaders();
HttpMethod requestMethod = requestHeaders.getAccessControlRequestMethod();
HttpHeaders headers = response.getHeaders();
headers.add(HttpHeaders.ACCESS_CONTROL_ALLOW_ORIGIN, requestHeaders.getOrigin());
headers.addAll(HttpHeaders.ACCESS_CONTROL_ALLOW_HEADERS, requestHeaders.getAccessControlRequestHeaders());
if (requestMethod != null) {
headers.add(HttpHeaders.ACCESS_CONTROL_ALLOW_METHODS, requestMethod.name());
}
headers.add(HttpHeaders.ACCESS_CONTROL_ALLOW_CREDENTIALS, "true");
headers.add(HttpHeaders.ACCESS_CONTROL_EXPOSE_HEADERS, ALL);
headers.add(HttpHeaders.ACCESS_CONTROL_MAX_AGE, MAX_AGE);
if (request.getMethod() == HttpMethod.OPTIONS) {
response.setStatusCode(HttpStatus.OK);
return Mono.empty();
}
return chain.filter(ctx);
}
}
5 修改 Gateway 配置文件
在仔细阅读过 Gateway 的文档你就会发现,原来 CorsFilter 早已经在 Gateway 里了,不需要自己写代码实现,而且更灵活,修改配置文件即可,结合配置中心使用,可以实现动态修改。
spring:
cloud:
gateway:
globalcors:
corsConfigurations:
'[/**]':
allowedOrigins: "docs.spring.io"
allowedMethods:
- GET
d 后端服务器处理 - Ngnix 方法
这里的 Nginx 尽做反向代理功能,浏览器访问页面在 a.com 的 Nginx 上,ajax 请求接口是 b.com,所以浏览器认为是跨域
Nginx 在 nginx.conf 上配(vhost 是约定做法,这样做不修改主文件)
include vhost/*.config;
创建 cors.conf
server{
listen 80; // 监听80端口
server_name b.com; // 监听向 b.com 发送的请求
location /{
proxy_pass http://ser432ver.53253bb.com:8080; // 转发到哪里
// Filter实现的功能在Nginx上再实现一遍
add_header Access-Control-Allow-Origin $http_origin; // $http_ 可以获取请求中相应的 header 参数
add_header Access-Control-Allow-Method *;
add_header Access-Control-Allow-Headers X-Custom-Header;
// 或者
// add_header Access-Control-Allow-Headers $http_access_control_request_headers;
add_header Access-Control-Allow-Credentials true;
add_header Access-Max-age 172800;
// 直接处理预检命令,if 后要带空格
if ($request_method = OPTIONS) {
return 200;
}
}
}
四、前端服务器解决跨域
但其实大部分情况下,我们会把前端应用和请求转发放在同一台 Nginx 上
server{
listen 80; // 监听80端口
server_name a.com; // 监听向 a.com 发送的请求
location / {
root html;
index index.html index.htm;
}
locltion /ajaxserver {
proxy_pass http://ser432ver.53253bb.com:8080; // 后端地址
}
}
这样实质是隐藏跨域,让浏览器认为没有访问其他域就不会发生跨域。
前端代码需要在每个 ajax 请求前都要加上/ajaxserver
五、参考资料
ajax跨域完全讲解
https://www.imooc.com/learn/947
SpringBoot使用CORS解决跨域请求问题
https://www.cnblogs.com/7788IT/p/10693073.html
Spring MVC之@RequestParam @RequestBody @RequestHeader 等详解
https://blog.csdn.net/summerSunStart/article/details/78676781
你不知道的「跨域 CORS」
https://www.jianshu.com/p/abb5f6bf92c3
关于跨域问题和安全性的一点理解
https://blog.csdn.net/jaytalent/article/details/52213576
浅谈跨域威胁与安全
https://www.freebuf.com/articles/web/208672.html
cors跨域中关于access-control-allow-headers导致的错误
https://www.jianshu.com/p/cecb73b26a11
什么是跨域?跨域解决方法
https://blog.csdn.net/qq_38128179/article/details/84956552
Spring Cloud配置跨域访问的五种方案?你用的是哪一种呢?
https://segmentfault.com/a/1190000017188296
servlet跨域请求
https://blog.csdn.net/qq_34135615/article/details/82900786
跨域(CORS) 解决方案中,为什么 Access-Control-Allow-Methods 不起作用?
https://segmentfault.com/q/1010000005067552/a-1020000005067822
原文地址:https://www.cnblogs.com/n031/p/11828797.html