跨域問題
現在絕大多數公司的項目都是前后端分離的，前后端分離后勢必會遇到跨域問題。如下圖
繼續debug發現，reponse為undefined，提示消息為Network Error。
所以當你和前端聯調的時候一直請求失敗，報網絡錯誤，一般情況下是后端沒有做跨域配置。
注意此時并不是后端沒有收到請求，而是收到請求了，也返回結果了，但是瀏覽器將結果攔截了，并且報錯。
同源策略
那么瀏覽器為什么會報錯呢？
因為瀏覽器基于安全考慮而引入的同源策略
當協議+域名+端口三者都相同時，才不會產生跨域問題，即同源。此時才能讀取到服務端的響應
當前url請求url 是否跨域
https://www.JAVAshitang.comhttp://www.javashitang.com. 是，協議不同https://www.javashitang.comhttp://book.javashitang.com. 是，域名不同https://www.javashitang.comhttp://www.javashitang.com:8000. 是，端口不同
為什么要有同源策略呢？
當然是為了安全起見，舉個例子，以銀行轉賬為例，看看你的錢是怎么沒的
這就是著名的CSRF攻擊（跨站請求偽造，當然還有很多其他方式），還有如果第5步不對請求的來源進行校驗，那么你的錢已經被轉走了
html頁面中的如下三個標簽是允許跨域加載資源的
- <img src=XXX>
- <link href=XXX>
- <script src=XXX>
如何解決跨域
雖然同源策略保證了安全，但一些合理的用途也會受到影響。解決跨域的方式有很多種，簡單介紹2個
JSONP
JSONP主要是利用<script>標簽將請求發送出去，來實現數據的加載，但這種方式有一個缺點，即只能支持GET請求，其他請求都不能支持，因為JSONP這種方式已經很少使用了，所以不做過多的介紹
CROS
非簡單請求
在正式的跨域請求前，發送一個OPTIONS請求去詢問服務器是否接受接下來的跨域請求，攜帶如下header
Origin：發起請求原來的域Access-Control-Request-Method：將要發起的跨域請求方式（GET/POST/…）Access-Control-Request-Headers：將要發起的跨域請求中包含的請求頭字段
服務器在返回中增加如下header來表明是否允許這個跨域請求。瀏覽器收到后進行檢查如果不符合要求則不會發起后續請求
Access-Control-Allow-Origin：允許哪些域來訪問（*表示允許所有域的請求）Access-Control-Allow-Methods：允許哪些請求方式Access-Control-Allow-Headers：允許哪些請求頭字段Access-Control-Allow-Credentials：是否允許攜帶Cookie
簡單請求
每次都要發送二次請求是不是很麻煩？所以做了優化
當請求方法是HEAD、GET、POST并且請求頭只有如下幾個時，被定義為簡單請求AcceptAccept-LanguageContent-LanguageLast-Event-IDContent-Type：(Application/x-www-form-urlencoded、multipart/form-data、text/plain)
簡單請求會在請求中加入Origin頭，直接發起請求，不會先詢問了。后端返回相應的header即可
Spring支持跨域
理解了跨域的本質，再看各種配置其實就是根據請求往reponse中增加header
利用Filter
配置如下Filter，CrossDomainFilter是對javax.servlet.Filter的封裝，本質上是一個Filter。
可以看到我多返回了一個header，Access-Control-Max-Age，他表明了詢問結果的有效期限，即在3600s之內瀏覽器可以不必再次詢問
@Component
@WebFilter(filterName = "crossDomain", urlPatterns = "/*")
public class CrossDomainFilter extends OncePerRequestFilter {
@Override
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
// 此處可以進行白名單檢測
if(CorsUtils.isCorsRequest(request)) {
response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Allow-Headers", request.getHeader("Access-Control-Request-Headers"));
response.setHeader("Access-Control-Allow-Methods", request.getHeader("Access-Control-Request-Method"));
response.setHeader("Access-Control-Max-Age", "3600");
}
// 是個OPTIONS請求，header已設好，不用執行后續邏輯，直接return
if(CorsUtils.isPreFlightRequest(request)) {
return;
}
filterChain.doFilter(request, response);
}
}
看一下用到的工具類
public abstract class CorsUtils {
// 請求中有 origin 這個header則返會true
public static boolean isCorsRequest(HttpServletRequest request) {
return (request.getHeader(HttpHeaders.ORIGIN) != null);
}
public static boolean isPreFlightRequest(HttpServletRequest request) {
return (isCorsRequest(request) && HttpMethod.OPTIONS.matches(request.getMethod()) &&
request.getHeader(HttpHeaders.ACCESS_CONTROL_REQUEST_METHOD) != null);
}
}
利用CorsRegistry
@Configuration
public class GlobalCorsConfig {
@Bean
public WebMvcConfigurer corsConfigurer() {
return new WebMvcConfigurer() {
@Override
public void addCorsMappings(CorsRegistry registry) {
// 添加映射路徑
registry.addMapping("/**")
// 允許的域
.allowedOrigins("*")
// 允許攜帶cookie
.allowCredentials(true)
// 允許的請求方式
.allowedMethods("GET","POST", "PUT", "DELETE")
// 允許的請求頭
.allowedHeaders("*");
}
};
}
}
利用@CrossOrigin注解
支持更細粒度的配置，可以用法方法上或者類上
@RestController
@RequestMapping("resource")
@CrossOrigin({"http://127.0.0.1:8080"})
public class ResourceController
其他方式支持跨域
看到這你可能會產生疑問，我們的項目中沒有跨域的配置啊，怎么還能支持跨域？那估計是把設置header這些活交給網關層來做了。
