5

跨域：后端工程师最熟悉的陌生“人”_华为云开发者社区的技术博客_51CTO博客

 1 year ago
source link: https://blog.51cto.com/u_15214399/6004171
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

摘要：跨域，对后端工程师来说，可谓既熟悉又陌生。

本文分享自华为云社区《​ ​后端老司机的跨域之旅​​》，作者： 勇哥java实战分享。

跨域，对后端工程师来说，可谓既熟悉又陌生。

这两个月我以架构师的角色参与一款教育产品的孵化，有了一段难忘的跨域之旅。

写这篇文章，我想分享我在跨域这个知识点的经历和思考，希望对大家有所启发。

跨域：后端工程师最熟悉的陌生“人”_CORS

1 遇见跨域

产品有多端：机构端，局方端 ，家长端等 。每端都有独立的域名，有的是在PC上访问，有的是通过微信公众号来访问，有的是扫码后H5展现。

跨域：后端工程师最熟悉的陌生“人”_CORS_02

接入层调用的接口域名统一使用 ​​api.training.com​​这个独立的域名，通过Nginx来配置请求转发。

通常，我们提到的跨域指：CORS。

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）, 它需要浏览器和服务器同时支持他，允许浏览器向跨源服务器发送XMLHttpRequest请求，从而克服 AJAX 只能同源使用的限制。

那么如何定义同源呢？我们先看下一个典型的网站的地址：

跨域：后端工程师最熟悉的陌生“人”_架构师_03

同源是指：协议、域名、端口号完全相同。

下表给出了与 URL ​​http://www.training.com/dir/page.html​​ 的源进行对比的示例:

跨域：后端工程师最熟悉的陌生“人”_架构师_04

当用户通过浏览器访问应用（​ ​http://admin.training.com​​）时，调用接口的域名非同源域名(​ ​http://api.training.com​​)，这是显而易见的跨域场景。

2 CORS详解

跨域资源共享标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站通过浏览器有权限访问哪些资源。

规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。

服务器确认允许之后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括 Cookies 和 HTTP 认证相关数据）。

跨域：后端工程师最熟悉的陌生“人”_跨域_05

2.1 简单请求

当请求同时满足如下条件时，CORS验证机制会使用简单请求， 否则CORS验证机制会使用预检请求。

1.使用GET、POST、HEAD其中一种方法；

2.只使用了如下的安全首部字段，不得人为设置其他首部字段；

  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type 仅限三种之一：text/plain，multipart/form-data，application/x-www-form-urlencoded：
  • HTML头部 header field字段：DPR、Download、Save-Data、Viewport-Width、WIdth

3.请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload 对象可以使用 XMLHttpRequest.upload 属性访问；

4.请求中没有使用 ReadableStream 对象。

简单请求模式，浏览器直接发送跨域请求，并在请求头中携带Origin的头，表明这是一个跨域的请求。 服务器端接到请求后，会根据自己的跨域规则，通过Access-Control-Allow-Origin和Access-Control-Allow-Methods响应头，来返回验证结果。

跨域：后端工程师最熟悉的陌生“人”_架构师_06

应答中携带了跨域头 Access-Control-Allow-Origin。使用 Origin 和 Access-Control-Allow-Origin 就能完成最简单的访问控制。本例中，服务端返回的 Access-Control-Allow-Origin: * 表明，该资源可以被任意外域访问。如果服务端仅允许来自 ​ ​http://admin.training.com​​ 的访问，该首部字段的内容如下：

Access-Control-Allow-Origin: http://admin.training.com



现在，除了 ​ ​http://admin.training.com​​，其它外域均不能访问该资源。



2.2 预检请求



浏览器在发现页面发出的请求非简单请求，并不会立即执行对应的请求代码，而是会触发预先请求模式。预先请求模式会先发送preflight request（预先验证请求），preflight request是一个OPTION请求，用于询问要被跨域访问的服务器，是否允许当前域名下的页面发送跨域的请求。在得到服务器的跨域授权后才能发送真正的HTTP请求。



OPTIONS请求头部中会包含以下头部：



跨域：后端工程师最熟悉的陌生“人”_CORS_07



服务器收到OPTIONS请求后，设置头部与浏览器沟通来判断是否允许这个请求。



跨域：后端工程师最熟悉的陌生“人”_CORS_08



如果preflight request验证通过，浏览器才会发送真正的跨域请求。



跨域：后端工程师最熟悉的陌生“人”_架构师_09



3 后端配置



后端配置我尝试过两种方式，经过两个月的测试，都能非常稳定的运行。



  • MND推荐的Nginx配置；
  • SpringBoot自带CorsFilter配置。



▍MND推荐的Nginx配置



Nginx配置相当于在请求转发层配置。



location / {
 if ($request_method = 'OPTIONS') {
 add_header 'Access-Control-Allow-Origin' '*';
 add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
 #
 # Custom headers and headers various browsers *should* be OK with but aren't
 #
 add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
 #
 # Tell client that this pre-flight info is valid for 20 days
 #
 add_header 'Access-Control-Max-Age' 1728000;
 add_header 'Content-Type' 'text/plain; charset=utf-8';
 add_header 'Content-Length' 0;
 return 204;
 }
 if ($request_method = 'POST') {
 add_header 'Access-Control-Allow-Origin' '*' always;
 add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
 add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always;
 add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
 }
 if ($request_method = 'GET') {
 add_header 'Access-Control-Allow-Origin' '*' always;
 add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
 add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always;
 add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
 }
}



在配置Access-Control-Allow-Headers属性的时候，因为自定义的header包含签名和token，数量较多。为了简洁方便，我把Access-Control-Allow-Headers配置成 * 。



在Chrome和firefox下没有任何异常，但在IE11下报了如下的错：



Access-Control-Allow-Headers 列表中不存在请求标头 content-type。



原来IE11要求预检请求返回的Access-Control-Allow-Headers的值必须以逗号分隔。



▍SpringBoot自带CorsFilter



首先基础框架里默认有如下跨域配置。



public void addCorsMappings(CorsRegistry registry) {
 registry.addMapping("/**")
 .allowedOrigins("*")
 .allowedMethods("POST", "GET", "PUT", "OPTIONS", "DELETE")
 .allowCredentials(true)
 .allowedHeaders("*")
 .maxAge(3600);
}



可是部署完成，进入还是报CORS异常：



跨域：后端工程师最熟悉的陌生“人”_架构师_10



从nginx和tomcat日志来看，仅仅收到一个OPTION请求，springboot应用里有一个拦截器ActionInterceptor，从header中获取token，调用用户服务查询用户信息，放入request中。当没有获取token数据时，会返回给前端JSON格式数据。



但从现象来看CorsMapping并没有生效。



为什么呢？实际上还是执行顺序的概念。下图展示了 过滤器，拦截器，控制器的执行顺序。



跨域：后端工程师最熟悉的陌生“人”_架构师_11



DispatchServlet.doDispatch()方法是SpringMVC的核心入口方法。



// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
 return;
}
// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());



那么CorsMapping在哪里初始化的呢？经过调试，定位于AbstractHandlerMapping。



protected HandlerExecutionChain getCorsHandlerExecutionChain(HttpServletRequest request,
HandlerExecutionChain chain, CorsConfiguration config) {
if (CorsUtils.isPreFlightRequest(request)) {
HandlerInterceptor[] interceptors = chain.getInterceptors();
chain = new HandlerExecutionChain(new PreFlightHandler(config), interceptors);
}
else {
chain.addInterceptor(new CorsInterceptor(config));
 }
return chain;
}



代码里有预检判断，通过PreFlightHandler.handleRequest()中处理，但是处于正常的业务拦截器之后。



最终选择CorsFilter 主要基于两点原因：



  • 过滤器的执行顺序优先级最高；
  • 通过调试CorsFilter的源码，发现源码有很多细节的处理。



private CorsConfiguration corsConfig() {
 CorsConfiguration corsConfiguration = new CorsConfiguration();
 corsConfiguration.addAllowedOrigin("*");
 corsConfiguration.addAllowedHeader("*");
 corsConfiguration.addAllowedMethod("*");
 corsConfiguration.setAllowCredentials(true);
 corsConfiguration.setMaxAge(3600L);
 return corsConfiguration;
}
@Bean
public CorsFilter corsFilter() {
 UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
 source.registerCorsConfiguration("/**", corsConfig());
 return new CorsFilter(source);
}



下面的代码里，allowHeader是通配符 * 的时候，CorsFilter在设置 Access-Control-Allow-Headers 的时候，会将 Access-Control-Request-Headers 以逗号拼接起来，这样就可以避免IE11响应头的问题。



public List<String> checkHeaders(@Nullable List<String> requestHeaders) {
 if (requestHeaders == null) {
 return null;
 }
 if (requestHeaders.isEmpty()) {
 return Collections.emptyList();
 }
 if (ObjectUtils.isEmpty(this.allowedHeaders)) {
 return null;
 }
 boolean allowAnyHeader = this.allowedHeaders.contains(ALL);
   List<String> result = new ArrayList<>(requestHeaders.size());
 for (String requestHeader : requestHeaders) {
 if (StringUtils.hasText(requestHeader)) {
 requestHeader = requestHeader.trim();
 if (allowAnyHeader) {
 result.add(requestHeader);
 }
 else {
 for (String allowedHeader : this.allowedHeaders) {
 if (requestHeader.equalsIgnoreCase(allowedHeader)) {
 result.add(requestHeader);
 break;
 }
 }
 }
 }
 }
 return (result.isEmpty() ? null : result);
}



浏览器的执行效果如下:



跨域：后端工程师最熟悉的陌生“人”_Access_12



4 preflight响应码：200 vs 204



后端配置完成之后，团队里的小伙伴问我：“勇哥，那预检请求返回的响应码到底是200还是204呀？”。这个问题真把我给问住了。



我司的API网关的预检响应码是200，CorsFilter预检响应码也是200。



MDN给的示例预检响应码全部是204。



​ ​https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS​​​ ​​​



跨域：后端工程师最熟悉的陌生“人”_架构师_13



我只能采取Google大法，赫然发现大名鼎鼎的API网关Kong的开发者也针对这个问题有一番讨论。



跨域：后端工程师最熟悉的陌生“人”_CORS_14



  1. MDN曾经推荐的preflight响应码是200 ，所以Kong也和MDN同步成200；The page was updated since then. See its contents on Sept 30th, 2018:​ ​https://web.archive.org/web/20180930031917/https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request​​
  2. 后来MDN将响应码修改204，于是Kong的开发者争论要不要和MDN保持同步。
    争论的核心点在于：有没有迫切的必要。200响应码运行得很好，似乎也将永远正常运行下去。而更换成204，不确定是否有隐藏问题。
  3. 说到底，框架开发者还是依赖于浏览器的底层实现。在这个问题上，没有足够权威的资料能够支撑框架开发者，而各个知识点都散落在网络的各个角落，充斥着不完整的细节和部分解决方案，这些都让框架开发者非常困惑。



最后，Kong的源码里预检响应码仍然是200，并没有和MDN保持同步。



我仔细查看了各大主流网站，95%预检响应码是200。而经过两个多月的测试，Nginx配置预检响应码204，在主流的浏览器Chrome , Firefox , IE11 也没有出现任何问题。



所以，200 works everywhere , 而204在当前主流的浏览器里也得到非常好的支持。



5 Chrome: 非安全私有网络



本以为跨域问题就这样解决了。没想到还是有一个小插曲。



产品总监需要给客户做演示，我负责搞定演示环境。申请域名，准备阿里云服务器，应用打包，部署，一切都很顺利。



可是在公司内网访问演示环境，有一个页面一直报CORS报错，报错内容类似下图：



跨域：后端工程师最熟悉的陌生“人”_CORS_15



跨域的错误类型是：InsecurePrivateNetwork。



这和原来遇到的跨域错误完全不一样，我心里一慌。马上Google , 原来这是chrome更新到94之后新的特性，可以手工关闭这个特性。



  1. 打开 tab 页面 chrome://flags/#block-insecure-private-network-requests
  2. 将其 Block insecure private network requests 设置为 Disabled, 然后重启就行了， 这样子就相当于把这个功能禁用掉。



跨域：后端工程师最熟悉的陌生“人”_架构师_16



但这样是治标不治本呀。有点诡异的是，当我们不在公司内网访问演示环境的时候，演示环境完全正常，出错的页面也能正常访问。



仔细看官方的文档，CORS-RFC1918 指出如下三种请求会受影响。



  • 公共网络访问私有网络；
  • 公共网络访问本地设备；
  • 私有网络访问本地设备。



跨域：后端工程师最熟悉的陌生“人”_架构师_17



这样，我把问题定位在这个出错的第三方接口地址上。公司很多产品都依赖这个接口服务。当在公司内网访问的时候，该域名映射地址类似：172.16.xx.xx。



而这个ip正好是rfc1918上规定的私有网络。



10.0.0.0     -  10.255.255.255 (10/8 prefix)
172.16.0.0   -  172.31.255.255 (172.16/12 prefix)
192.168.0.0  - 192.168.255.255 (192.168/16 prefix)



内网通过Chrome访问这个页面的时候，会触发非安全私有网络拦截。



如何解决呢？官方给出的方案分两步走：



  1. 私有网络只能通过Https来访问；
  2. 未来，添加特定的预检头，比如说：Access-Control-Request-Private-Network等。



当然还有一些临时方法：



  • 关闭Chrome该特性;
  • 换用其他浏览器比如Firefox;
  • 关闭网络内网开手机热点;
  • 修改本地host绑定外网ip。



基于官方的方案 ，生产环境完全使用Https，公司内网访问就没有出现这样的跨域问题了。



跨域：后端工程师最熟悉的陌生“人”_架构师_18



API网关非常适合当前产品的架构。架构设计之初，系统多端都会调用我司的API网关。API网关可以SAAS部署和私有化部署，有单独的域名，提供完善的签名算法。考虑到上线时间节点，团队成员对于API网关的熟悉程度以及多套环境部署投入时间成本，为了尽快交付，从架构层面，我做了一些平衡和妥协。



接入层调用的接口域名统一使用 ​​api.training.com​​这个独立的域名，，通过Nginx来配置请求转发。同时，我和前端Leader统一了前后端协议，保持和我司API网关一致，为后续切回API网关做前置准备。



API网关可以做鉴权，限流，灰度等，同时可以配置CORS。内部服务端不用特别关注跨域这个问题。



跨域：后端工程师最熟悉的陌生“人”_API_19



同时，在解决跨域的问题过程中，我的心态也发生了变化。从最初的轻视，到逐渐沉下心来，一步步理解CORS的原理，分清楚不同解决方案的优缺点，事情也就慢慢顺遂起来。 我也观察到：”有的项目组已经反馈过Chrome非安全私有网络问题，并给出了解决方案。对于技术管理者来讲，一定要重视项目中反馈的问题，做好梳理分析，整理预案。这样当同类问题出现时，也会条理有序“。



​ ​点击关注，第一时间了解华为云新鲜技术~​​

        

        

            

                report
            

        

    







        
Recommend

        



                

    
About Joyk

    
 





Aggregate valuable and interesting links.

Joyk means Joy of geeK