引言
前後端分離的專案雖然降低了耦合度，但是引發的各種問題也隨之而來。後端專案由Tomcat部署(監聽8080埠)，前端專案則部署在Nginx上（監聽80、443等非8080埠），前端頁面載入速度大大提高了，而當ajax請求後端介面的時候卻報錯了。
同源策略
同源策略，它是由Netscape提出的一個著名的安全策略。現在所有支援JavaScript 的瀏覽器都會使用這個策略。所謂同源是指，域名，協議，埠相同。
前端地址：
http://127.0.0.1:63344
後端地址：
http://127.0.0.1:8080
這兩個地址雖然ip地址和協議都一樣，但是埠不一樣，所以並不滿足同源，這樣就造成了跨域的問題。
解決方案
配置addCorsMappings
新增一個類實現 WebMvcConfigurer 介面，然後給這個類加上 @Configuration 註解，最後實現 addCorsMappings 方法就ok了。
@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOrigins("*")
.allowedMethods("POST", "GET", "PUT", "OPTIONS", "DELETE")
.maxAge(3600)
.allowCredentials(true);
}
}
複製程式碼請求正常
這就完事了？這麼簡單的嗎？
登陸後臺管理看看
wtf?
為何是OPTIONS請求？
按照我的邏輯，上面那個報錯的介面應該是一個GET請求，可為什麼發的是OPTIONS請求？翻閱各種資料，各種百度google，各種倒騰，各種頭疼，最後。。。我掀開了被子，驚奇的發現。。。被窩可真暖和啊！（先睡一覺再說）
原因
原來瀏覽器會在傳送真正請求之前，先傳送一個方法為OPTIONS的預檢請求 Preflighted requests 這個請求是用來驗證本次請求是否安全的，而且並不是所有請求都會傳送，需要符合以下條件：
- 請求方法不是GET/HEAD/POST
- POST請求的Content-Type並非application/x-www-form-urlencoded, multipart/form-data, 或text/plain
- 請求設定了自定義的header欄位
對於管理端的介面，我有對介面進行許可權校驗，每次請求需要在header中攜帶自定義的欄位（token），所以瀏覽器會多傳送一個OPTIONS請求。
那為什麼OPTIONS請求報錯了。。。
經過debug發現，OPTIONS請求只會攜帶自定義的欄位，並不會將相應的值帶入進去，而後臺校驗token欄位時 token為NULL，所以驗證不通過，丟擲了一個異常。
放行OPTIONS
我換了一種解決跨域的方法，使用攔截器解決跨域問題，並且針對OPTIONS請求做放行處理。
新增一個攔截器類 CorsInterceptor 實現 HandlerInterceptor 介面
@Component
public class CorsInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Allow-Methods", "GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS");
response.setHeader("Access-Control-Max-Age", "86400");
response.setHeader("Access-Control-Allow-Headers", "*");
// 如果是OPTIONS則結束請求
if (HttpMethod.OPTIONS.toString().equals(request.getMethod())) {
response.setStatus(HttpStatus.NO_CONTENT.value());
return false;
}
return true;
}
}
複製程式碼需將跨域攔截器放在校驗攔截器之上
我把原來的跨域配置 addCorsMappings 刪除了
@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
@Resource
private LoginInterceptor loginInterceptor;
@Resource
private CorsInterceptor corsInterceptor;
@Override
public void addInterceptors(InterceptorRegistry registry) {
// 跨域攔截器需放在最上面
registry.addInterceptor(corsInterceptor).addPathPatterns("/**");
// 校驗token的攔截器
registry.addInterceptor(loginInterceptor).addPathPatterns("/admin/**");
}
}
複製程式碼OPTIOINS請求沒問題了
也相繼傳送了GET請求
總結
晚安！
補充說明
Access-Control-Allow-Credentials 響應頭表示是否可以將對請求的響應暴露給頁面。返回 true 則可以，其他值均不可以。Credentials可以是 cookies, authorization headers 或 TLS client certificates。如果被設定為true，伺服器不得設定 Access-Control-Allow-Origin 的值為 *，需要指定域名，否則當需要傳送 Cookie 到伺服器時，瀏覽器響應時將會報錯。
測試
Ajax請求開啟 withCredentials 屬性
xhrFields: {
withCredentials: true
}
複製程式碼後端跨域配置不變時，瀏覽器請求結果報錯
指定 Access-Control-Allow-Credentials 的值為 http://127.0.0.1:63344，再次請求後正常
最終配置
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
// 此處配置的是允許任意域名跨域請求，可根據需求指定
response.setHeader("Access-Control-Allow-Origin", request.getHeader("origin"));
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Allow-Methods", "GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS");
response.setHeader("Access-Control-Max-Age", "86400");
response.setHeader("Access-Control-Allow-Headers", "*");
// 如果是OPTIONS則結束請求
if (HttpMethod.OPTIONS.toString().equals(request.getMethod())) {
response.setStatus(HttpStatus.NO_CONTENT.value());
return false;
}
return true;
}
複製程式碼