什么是跨域跨域的3种解决⽅案
所谓同源（即指在同⼀个域）就是两个页⾯具有相同的协议（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 等等。
并不是请求或响应独有的参数
JSONP 原理
以 JQuery 为例，发送 ajax 请求的时候，设置dataType:"jsonp"，将使⽤ JSONP ⽅式调⽤函数，函数的 url 变为myurl?callback=e5bbttt的形式，e5bbttt 就是⼀个临时⽅法名，后端会根据callback的值返回⼀个 js 脚本，如
<script>
e5bbttt({"a":"aaa","b":"bbb"});
</script>
jquery是什么有什么作用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 属性定义。
JSONP 的弊端
需要服务器改动代码
只⽀持 GET 请求
发送的不是 xhr 请求
不安全
后端解决跨域
跟⽤户数据有关的就是动态请求，没有数据的是静态请求，⽐如 css js，so，HTTP 服务器（Apache、Nginx 等）⾄少做了两个作⽤
HTTP 服务器，处理静态请求
反向代理，负载均衡
在服务器端解决跨域有2种解决思路
在被调⽤后端应⽤解决：在响应头增加指定字段，告诉浏览器允许调⽤。这种解决⽅案的请求是直接从浏览器发送给后端服务器，在浏览器上会看到 b 的 url
在前端服务器解决：这是隐藏跨域的解决⽅案。这种跨域请求不是直接从浏览器发送的，⽽是从中间的 http 服务器（前端应⽤所在服务器）转发过去的，在浏览器中看到的还是 a 的 url，所以不会认为是跨域。但是该到 b 的请求还是会到 b
跨域原理及后端解决思路
依据浏览器同源策略，⾮同源脚本不可操作其他源下⾯的对象。想要操作其他源下的对象就需要跨域。综上所述，在同源策略的限制下，⾮同源的⽹站之间不能发送ajax 请求。如有需要，可通过降域或其他技术实现。
为了解决浏览器跨域问题，W3C 提出了跨源资源共享⽅案，即 CORS(Cross-Origin Resource Sharing)。
CORS 可以在不破坏即有规则的情况下，通过后端服务器实现 CORS 接⼝，就可以实现跨域通信。
CORS 将请求分为两类：简单请求和⾮简单请求，分别对跨域通信提供了⽀持。
简单请求
在 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: st
Host: st
对于简单请求，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-Typ e、Expires、Last-Modified、Pragma
⾮简单请求
⼀般是发送 JSON 格式的 ajax 请求，或带有⾃定义头的请求
对于⾮简单请求的跨源请求，浏览器会在真实请求发出前，增加⼀次 OPTION 请求，称为预检请求(preflightrequest)。预检请求将真实请求的信息，包括请求⽅法、⾃定义头字段、源信息添加到 HTTP 头信息字段中，询问服务器是否允许这样的操作
例如⼀个 GET 请求的预检请求，包含⼀个⾃定义参数 X-Custom-Header
OPTIONS /test HTTP/1.1
Origin: st
Access-Control-Request-Method: GET // 请求使⽤的 HTTP ⽅法
Access-Control-Request-Headers: X-Custom-Header // 请求中包含的⾃定义头字段
Host: st
服务器收到请求时，需要分别对 Origin、Access-Control-Request-Method、Access-Control-Request-Headers 进⾏验证，验证通过后，会在返回 HTTP 头信息中添加：
HTTP/1.1 200 OK
Access-Control-Allow-Origin: st // 允许的域
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
后端应⽤处理 - Filter&HttpServletResponse ⽅法
这种⽅法不会⽤到 Spring，对 Servlet 也可以使⽤
在 l 中配置
<!-- 跨域 -->
<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 = Header("Origin");
if ("abcdefg".contains(origin)) { // 满⾜指定的条件
res.addHeader("Access-Control-Allow-Origin", origin);
}
res.addHeader("Access-Control-Allow-Origin", "st");
// 允许跨域的⽅法，可设置*表⽰所有
res.addHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
// 允许的⾃定义字段
String headers = Header("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() {
}
}
后端应⽤处理 - 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）决定是否放⾏
在 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";
}
增加 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){}
结合 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("localhost:8088");
// 允许 HEADER 或 METHOD ， * 为全部
config.addAllowedHeader("*");
config.addAllowedMethod("*");
FilterRegistrationBean<CorsFilter> bean = new FilterRegistrationBean<>(new CorsFilter(source));
// 这个顺序很重要，为避免⿇烦请设置在最前
bean.setOrder(0);
return bean;
}
}
以上这种⽅案如果微服务多的话，需要在每个服务的主类上都加上这么段代码，增加了维护量。
这三种⽅案都是在 SpringBoot 的基础上实现的解决⽅案，在模块较多或者接⼝较多的情况下不易维护。
既然 Spring Cloud ⾃带 Gateway，下⾯就讲讲使⽤ Gateway 的跨域解决⽅案。（Gateway 是取代不断跳票的 Zuul 的新⼀代⽹关）
在 Gateway 增加 CorsFilter
4 5 ⽅法未验证
这种⽅案跟⽅案三有些类似，只不过是放到了 Gateway 端，对于有多个微服务模块的情况下，就⼤⼤减少了 SpringBoot 模块端的代码量，让各个模块更集中精⼒做业务逻辑实现。这个⽅案只需要在 Gateway ⾥添加 Filter 代码类即可。
import t.annotation.Configuration;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpMethod;
import org.springframework.http.HttpStatus;
import org.springframework.active.ServerHttpRequest;
import org.springframework.active.ServerHttpResponse;
import org.s.CorsUtils;
import org.springframework.web.server.ServerWebExchange;
import org.springframework.web.server.WebFilter;
import org.springframework.web.server.WebFilterChain;
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 = Request();
String path = Path().value();
ServerHttpResponse response = Response();
if ("/favicon.ico".equals(path)) {
response.setStatusCode(HttpStatus.OK);
pty();
}
if (!CorsUtils.isCorsRequest((HttpServletRequest) request)) {
return chain.filter(ctx);
}
HttpHeaders requestHeaders = Headers();
HttpMethod requestMethod = AccessControlRequestMethod();
HttpHeaders headers = Headers();
headers.add(HttpHeaders.ACCESS_CONTROL_ALLOW_ORIGIN, Origin());
headers.addAll(HttpHeaders.ACCESS_CONTROL_ALLOW_HEADERS, AccessControlRequestHeaders());
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 (Method() == HttpMethod.OPTIONS) {
response.setStatusCode(HttpStatus.OK);
pty();
}
return chain.filter(ctx);
}
}
修改 Gateway 配置⽂件
在仔细阅读过 Gateway 的⽂档你就会发现，原来 CorsFilter 早已经在 Gateway ⾥了，不需要⾃⼰写代码实现，⽽且更灵活，修改配置⽂件即可，结合配置中⼼使⽤，可以实现动态修改。
spring:
cloud:
gateway:
globalcors:
corsConfigurations:
'[/**]':
allowedOrigins: "docs.spring.io"
allowedMethods:
- GET
后端服务器处理 - Ngnix ⽅法
这⾥的 Nginx 尽做反向代理功能，浏览器访问页⾯在 a 的 Nginx 上，ajax 请求接⼝是 b，所以浏览器认为是跨域
Nginx 在 f 上配（vhost 是约定做法，这样做不修改主⽂件）
include vhost/*.config;
创建 f
server{
listen 80; // 监听80端⼝
server_name b; // 监听向 b 发送的请求
location /{
proxy_pass ser432ver.53253bb: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; // 监听向 a 发送的请求
location / {
root html;
index index.html index.htm;
}
locltion /ajaxserver {
proxy_pass ser432ver.53253bb:8080; // 后端地址
}
}
这样实质是隐藏跨域，让浏览器认为没有访问其他域就不会发⽣跨域。
前端代码需要在每个 ajax 请求前都要加上/ajaxserver
参考资料
ajax跨域完全讲解
SpringBoot使⽤CORS解决跨域请求问题
Spring MVC之@RequestParam @RequestBody @RequestHeader 等详解你不知道的「跨域 CORS」
关于跨域问题和安全性的⼀点理解
浅谈跨域威胁与安全
cors跨域中关于access-control-allow-headers导致的错误
什么是跨域？跨域解决⽅法
Spring Cloud配置跨域访问的五种⽅案？你⽤的是哪⼀种呢？
servlet跨域请求
跨域(CORS) 解决⽅案中，为什么 Access-Control-Allow-Methods 不起作⽤？
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论