1.跨域访问
概念
HTTP 协议中的 Origin Header 存在于请求中,用于指明当前请求来自于哪个站点。
字段内容
Origin 仅仅包含站点信息,不包含任何路径信息。
语法
Origin: ""
Origin: "<schema>://<host>[:port]"
// 例如
Origin: "https://baidu.com"
// 错误示范,包含了路径信息
Origin: "https://baidu.com/"
应用
CORS
当我们的浏览器发出跨站请求时,行为正确的服务器会校验当前请求是不是来自被允许的站点。服务器就是通过 Origin 字段的值来进行的判断。
当服务器的配置出错时,比如配置成了 https://baidu.com/,则可能造成一些难以理解的问题。
比如有的浏览器(IE)能够请求成功,而有的浏览器却请求失败(Chrome)。这不是因为前一个浏览器行为正确,而是因为前一个浏览器发出请求时没有带上 Origin 而后一个浏览器带上了正确的 Origin。而在服务器端,因为没有 Origin Header,所以认为这不是一次 CORS 请求,所以没有进行 CORS 校验。这也反过来要求服务端强制请求带上 Origin Header,才能进一步保证服务器的安全性。
2. 为什么页面一定要加Origin源码分析
/**
* 这里为支持的请求头,如果有自定义的header字段请自己添加
*/
private static final String ALLOWED_HEADERS = "X-Requested-With, Tenant-Id, Blade-Auth, Content-Type, Authorization, credential, X-XSRF-TOKEN, token, username, client";
private static final String ALLOWED_METHODS = "GET,POST,PUT,DELETE,OPTIONS,HEAD";
private static final String ALLOWED_ORIGIN = "*";
private static final String ALLOWED_EXPOSE = "*";
private static final String MAX_AGE = "18000L";
/**
* 跨域配置
*/
@Bean
public WebFilter corsFilter() {
return (ServerWebExchange ctx, WebFilterChain chain) -> {
ServerHttpRequest request = ctx.getRequest();
if (CorsUtils.isCorsRequest(request)) {
ServerHttpResponse response = ctx.getResponse();
HttpHeaders headers = response.getHeaders();
headers.add("Access-Control-Allow-Headers", ALLOWED_HEADERS);
headers.add("Access-Control-Allow-Methods", ALLOWED_METHODS);
headers.add("Access-Control-Allow-Origin", ALLOWED_ORIGIN);
headers.add("Access-Control-Expose-Headers", ALLOWED_EXPOSE);
headers.add("Access-Control-Max-Age", MAX_AGE);
headers.add("Access-Control-Allow-Credentials", "true");
if (request.getMethod() == HttpMethod.OPTIONS) {
response.setStatusCode(HttpStatus.OK);
return Mono.empty();
}
}
return chain.filter(ctx);
};
}
调用此方法会判断:
public static boolean isCorsRequest(ServerHttpRequest request) {
return request.getHeaders().get("Origin") != null;
}
注意此方法通过gateway中对跨域访问进行处理
或者使用下面的方式也可以:
@Configuration // gateway
public class GulimallCorsConfiguration {
@Bean // 添加过滤器
public CorsWebFilter corsWebFilter(){
// 基于url跨域,选择reactive包下的
UrlBasedCorsConfigurationSource source=new UrlBasedCorsConfigurationSource();
// 跨域配置信息
CorsConfiguration corsConfiguration = new CorsConfiguration();
// 允许跨域的头
corsConfiguration.addAllowedHeader("*");
// 允许跨域的请求方式
corsConfiguration.addAllowedMethod("*");
// 允许跨域的请求来源
corsConfiguration.addAllowedOrigin("*");
// 是否允许携带cookie跨域
corsConfiguration.setAllowCredentials(true);
// 任意url都要进行跨域配置
source.registerCorsConfiguration("/**",corsConfiguration);
return new CorsWebFilter(source);
}
}
1.跨域解释
1.1 怎么知道我遇到了跨域问题
如果项目没做前后端分离,是不会有跨域问题的。前后端分离的项目中,前端调用后台服务时,报错 No 'Access-Control-Allow-Origin' header is present on the requested resource,你就是遇到了跨域问题。另外,前端调试墙裂推荐使用chrome,使用QQ浏览器遇到过跨域访问不了但是不报错的坑爹事件。
1.2 为什么有跨域问题
浏览器的同源策略拒绝了我们的请求。 所谓同源是指,域名,协议,端口相同,浏览器执行一个脚本时同源的脚本才会被执行。如果非同源,那么在请求数据时,浏览器会在控制台中报上面的异常,提示拒绝访问。这是为了同一浏览器打开多个网站时,保护你的A网站登陆信息不被B网站拿去访问A网站,B网站登陆信息同理。
1.3 怎么解决跨域问题
网上的文章对于解决跨域问题的介绍都很详细了。但对于使用Nginx解决跨域大多写的不太详细或者太详细以至于干扰因素太多,看了容易造成误解。这里做个总结。
2.使用nginx解决跨域问题
2.1 先明确几个概念
首先明确一个概念,前端项目、后端项目、以及nginx,这就是三个server项目,他们只是互相之间交流数据;
三个项目都有自己的ip:port组合,哪怕你是在同一台服务器上启动这三个server,他们的port也是不可能有一样的;
所以,前端项目,不论访问nginx还是访问后端项目,都会产生跨域问题。
2.2 解决跨域问题
以下举例都是项目在同一台机器上,所以IP相同,只以端口区分前端项目(8081)、后端项目(8082)和nginx(8080)。
2.2.1 方法1:在nginx中配置地址重写(或者转发也行)
访问地址以/video_resource开头的都会被这个模块捕获,转发到http://192.168.137.189:8082的后端项目上去。例如此时访问http://192.168.137.189:8080/video_resource/userList/engineer,就会转发到http://192.168.137.189:8082/userList/engineer。
访问地址以/js开头的也被这个模块捕获,转发到http://192.168.137.189:8082的前端项目上去。
server
{
listen 8080;
location /resource {
rewrite ^/resource/?(.*)$ /$1 break;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://192.168.137.189:8082/; # 转发地址
}
location /js {
rewrite ^/js/?(.*)$ /$1 break;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://192.168.137.189:8081/; # 转发地址
}
}
此时统一通过nginx访问前后端项目,通过/js标识转发到前端项目,通过/resource标识转发到后端项目。浏览器同源策略记录的就是http://192.168.137.189:8080/,浏览器也只访问这个nginx的8080地址,跨域问题也就得到了解决。
2.2.2 方法2:nginx中添加允许跨域请求头
server
{
listen 8080;
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers X-Requested-With;
add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
location /resource {
rewrite ^/resource/?(.*)$ /$1 break;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://192.168.137.189:8082/; # 转发地址
}
}
这就和不用nginx,直接在后端项目中(tomcat或者自己写的服务端代码)配置允许跨域一样,只不过把允许跨域的配置放在nginx中,这个配置解决了前端项目访问nginx的跨域问题,而nginx访问后端项目不存在跨域问题(不是浏览器,没有同源策略限制)。此时nginx对于后端就相当于一个代理分发服务器。
3.总结
浏览器的同源策略只记录他访问对象的ip和port,访问其他资源如果还是这个ip:port,就不存在跨域问题,如果不是这个ip:port,就用nginx讲这个ip:port转发到要访问的ip:port,让他仍然访问这个同源策略的ip:port。
3. 使用nginx设置跨域
Nginx配置(推荐)核心思想就是通过nginx或者其他反代工具,将本是跨域的接口地址代理到本地,再调用本地代理后的地址,即可解决跨域问题
参考: https://www.jianshu.com/p/1080014a234f
总结
- 从gateway配置跨域固然方便,配置一次,其他所有请求都支持了,但是这样会或多或少影响系统的性能,深一层次想,这其实并不是服务端该做的事情
- Nginx配置反代的模式,虽然看上去麻烦,需要每个地方都配置跨域,但是由于nginx的高性能,将API反向代理后,并不会有明显的损耗,同时也变相降低了服务端的压力。所以推荐使用Nginx或其他反代工具来解决跨域问题。