如何快速学习Java系列之跨域（CORS）请求（day5）

　　昨天（第 4 天），我们实现了第一个 API  —— echo ，并通过 httpie  成功调用。今天我们来尝试一下用浏览器来调用是否还能成功调通？答案是否定的。原因就是我们今天要学习的 浏览器同源策略  导致的，同时引出了 CORS  实现跨域访问 。本文主要内容包括：CORS 同源策略支持 CORS  跨域访问预检请求 Preflight Request
　　浏览器调用 API 的尝试
　　先来回顾一下，在 day 4  文章的实例中，我们已经通过 httpie  成功的调用了 echo  接口，如下图：
　　非浏览器成功调用
　　下面我们来写个 JavaScript  脚本，通过浏览器来调用 echo  接口。
　　直接运行 HTML 文件调用接口
　　新建一个 html  文件，代码如下：                   call /api/util/echo     
　　保存后，双击用浏览器打开该 HTML ，点击按钮即可触发调用 echo  接口，调用结果如下：
　　执行失败，报被 CORS 策略阻塞
　　通过 HTTP 服务器调用接口
　　下面是 VUE  代码，添加到 VUE  项目中，执行 yarn -dev  命令运行，点击按钮，触发调用 echo  接口。  
　　这种方式运行是有 HTTP  服务器的，调用的结果如下图，它更清晰的指出了源域 IP ：
　　执行失败，报被 CORS 策略拒绝
　　跨域（CORS）和同源策略（SOP）
　　CORS ：Cross Origin Resource Sharing , 俗称＂跨域 ＂，全称＂跨域资源共享 ＂，是每个 WEB  项目开发人员，不管是前端还是后端，都会遇到的问题。
　　跨域问题是浏览器为了安全才有的，使用其它客户端工具，比如 httpie 、curl  等都没有该问题。
　　Web  浏览器实现了一种被称为＂同源策略 ＂的安全机制，防止网页在不同域中访问资源，包括 API ；而 CORS  提供了一种安全的方式，允许一个域（源域，用 origin  表示）调用另一个域中的资源，即允许在一个域下运行的 web  应用程序访问另一个域。
　　SOP ：Same Origin Policy ， 同源策略 。同源 是指协议、域名和端口都相同，任何一个不相同都不算同源 。
　　跨域请求和响应
　　CORS Request  有两类：＂simple＂ requests  和 ＂preflight＂ requests ，浏览器自己会决定使用哪种请求，无需我们人为的干预。我们需要了解该机制即可。简单请求 Simple requests  (GET, POST, HEAD )
　　当请求满足下面条件时，浏览器将该请求视为＂simple ＂请求：
　　（1）使用 GET 、POST  或 HEAD  请求
　　（2）使用 CORS safe-listed header
　　（3）使用 Content-Type header  值为 application /x-wwww-form-urlencoded 、multipart /form-data  或 text /plain
　　（4）没有在任何 XMLHttpRequestUpload  对象上注册事件侦听器
　　（5）请求中未使用 ReadableStream  对象
　　满足这些条件的请求，则被允许继续正常执行，不会被阻止，并且在返回响应时检查 Access-Control-Allow-Origin  header 。预检请求 Preflight requests  (OPTIONS )
　　如果不是＂simple＂ request ，浏览器将使用 HTTP  OPTIONS  方法自动发出预检请求 。 预检请求用于确定服务端确切的 CORS  能力，判断服务端是否理解预期的 CORS  协议。 如果 OPTIONS  调用的结果指示无法请求，则不会再发起对服务端的实际请求。
　　预检请求将请求模式设置为 OPTIONS ，并设置一组 header  来描述接下来的请求：
　　（1）Access-Control-Request-Method ：请求的预期方法（如 GET、 POST ）
　　（2）Access-Control-Request-Headers ：将随请求一起发送的自定义 header  的名称
　　（3）Origin ：current origin
　　预检请求举例：curl -i -X OPTIONS localhost:3031/api/echo  -H ＂Access-Control-Request-Method: GET＂  -H ＂Access-Control-Request-Headers: Content-Type, Accept＂  -H ＂Origin: http://localhost:3030＂
　　这个例子表示，客户端向服务端询问：我想向从 http://localhost:3030  向 http://localhost:3031 /api/echo 发起一个 Get  请求，该请求包含 ＂Content-Type , Accept ＂ header ，是否可以？
　　服务器判断后，在响应中包含一些类似 Access-Control-*  的 header ，以指示是否允许随后的请求。 这些 header  有如下几种：
　　（1）Access-Control-Allow-Origin : 表示允许发请求的源, ＂*＂ 表示允许所有源访问
　　（2）Access-Control-Allow-Methods : 允许的 HTTP methods ，以逗号分隔
　　（3）Access-Control-Allow-Headers : 允许发送的 custom headers ，以逗号分隔
　　（4）Access-Control-Max-Age : preflight request  预请求响应结果的缓存时长，在这段时长内，再次调用该接口不用进行预请求调用。
　　一个 preflight  请求的 Response  可能是像下面这样的：HTTP/1.1 204 No Content Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE Vary: Access-Control-Request-Headers Access-Control-Allow-Headers: Content-Type, Accept Content-Length: 0 Date: Fri, 05 Apr 2023 11:41:08 GMT Connection: keep-alive
　　看到这里，是不是已经明白为什么在浏览器调试工具＂网络＂窗口中经常看到发出一次请求，有两条 log 的原因了吧？
　　一次调用显示两条 log
　　对的，没错就是因为其中一条是预检请求 ，另外一条才是真实请求 。
　　后端跨域的实现添加跨域配置
　　后端跨域配置
　　添加 CorsConfig.java 文件，代码如下。import org.springframework.context.annotation.Configuration; import org.springframework.web.servlet.config.annotation.CorsRegistry; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;  @Configuration public class CorsConfig implements WebMvcConfigurer {     @Override     public void addCorsMappings(CorsRegistry registry) {         registry.addMapping(＂/**＂)                 // When allowCredentials is true, allowedOrigins cannot contain the special value ＂*＂ since that cannot be set on the ＂Access-Control-Allow-Origin＂ response header.                 // To allow credentials to a set of origins, list them explicitly or consider using ＂allowedOriginPatterns＂ instead.                 .allowedOrigins(＂*＂)                 //.allowedOriginPatterns(＂*＂)                 .allowedMethods(＂GET＂, ＂POST＂, ＂DELETE＂)                 .allowedHeaders(＂*＂)                 // restful api 是无状态的，无需缓存 cookie 等信息                 //.allowCredentials(true)                 // Access-Control-Max-Age header 表明预检请求响应的有效时间。在有效时间内，浏览器无须为同一请求再次发起预检请求。                 // 请注意，浏览器自身维护了一个最大有效时间，如果该首部字段的值超过了最大有效时间，将不会生效。                 // 在预检中，浏览器发送的头中包含有 HTTP 方法和真实请求中会用到的头。                 // 也就是说对于同样的请求，在 max-age 规定的时间内就不用再次通过预检了，就可以直接请求了，单位s                 .maxAge(1800);     } }跨域调用
　　支持跨域之后，我们再分别用 httpie  和 浏览器来调用 echo  接口看看有什变化。
　　跨域前后 httpie 调用结果对比
　　跨域前后 chrome 调用结果对比
　　从上面实践可以看到，支持跨域后，浏览器能成功调用 echo  接口了。
　　预检请求（Preflight Request）实战
　　最后我们再来增加一个 delete  接口，来亲自见识一下＂预检请求 ＂。
　　从上面的解释，我们知道预检请求不能是 GET ，POST  这种请求，而我们已有的 echo  接口是一个 POST  请求，所以需要新增一个符合条件的接口，这里我们增加一个 HTTP  DELETE  接口来演示。
　　增加 delete 接口添加接口
　　增加一个新的 Controller ，并添加 delete  接口，采用 @DeleteMapping  表示使用 HTTP  DELETE  方法来请求。import com.example.springdemo.dto.ProductQueryDto; import com.example.springdemo.model.Result; import org.springframework.web.bind.annotation.*;  @RestController @RequestMapping(＂api/product＂) public class ProductController {     @DeleteMapping(＂delete＂)     public Result delete(@RequestBody ProductQueryDto param) {         System.out.printf(＂[product][del] %s ＂, param.getId());         Result res = new Result<>();         return res.setData(param.getId());     } }
　　增加 ProductQueryDto ，用于接口传参。这里大家先不用去管什么是 DTO ，什么是 Model ，后面的分享会逐一说明的。import lombok.Getter; import lombok.Setter;  @Getter @Setter public class ProductQueryDto {     private String id; }添加调用 delete 接口的 JavaScript 代码call /api/product/delete   运行并调用 delete 接口
　　一次调用，有两条log
　　点击这两条数据，查看两次调用的请求头和请求响应，对比如下图：
　　预检请求和真正请求的对比
　　小结，今天掌握了浏览器的同源策略 SOP，实现跨域访问 CORS 的方法，学习了预检请求 Preflight Request 和 Simple Request，自己定义了一个符合需要 Preflight Request 的接口，通过代码亲自做了实践。