前后端分離項目，如何解決跨域問題？
跨域問題是前后端分離項目中非常常見的一個問題，舉例來說，編程貓(codingmore)學習網站的前端服務跑在 8080 端口下，后端服務跑在 9002 端口下，那么前端在請求后端接口的時候就會出現跨域問題。
403 Forbidden 是HTTP協議中的一個狀態碼(Status Code)，意味著后端服務雖然成功解析了請求，但前端卻沒有訪問該資源的權限。
那怎么解決這個問題呢?通常有兩個思路：
- 前端使用 Nodejs 代理(開發環境下，生產環境下可以用 Nginx 替代)
- 或者后端開啟跨域資源共享
一、關于跨域
跨域對于前后端開發者來說，就像一塊狗皮膏藥，無論是面試還是開發中，都會經常遇到。
之所以出現跨域問題，是因為瀏覽器的同源策略，為了隔離潛在的惡意文件，為了防御來自歪門邪道的攻擊，瀏覽器限制了從同一個源加載的文檔或腳本與來自另一個源的資源進行交互。
前面我們提到了，前端跑在 8080 端口下，后端跑在 9002 端口下，這種情況就屬于不同的源(域名不同，協議不同，端口不同)，所以 8080 端口下的前端請求直接訪問 9002 端口下的后端接口時就訪問失敗了。
那正確的打開方式是什么呢?我們前面也提到了，前端使用 Nodejs 代理或者后端開啟跨域資源共享，我們一一來實踐下。
二、Nodejs 代理
在 Nodejs 出現之前，JavaScript 編寫的程序通常需要在用戶的瀏覽器上執行，Node.js 出現后，JavaScript 也能用于服務端編程了。Nodejs 一系列的內置模塊使得程序可以脫離 IIS、Apache 這種 Web 服務作為獨立的服務器執行。
我們使用 Nodejs 來解決跨域問題的思路就是，在本地創建一個虛擬服務器，對 8080 端口下的前端請求進行代理，同時接收 9002 端口下的服務器端響應，這樣服務端和服務端進行數據的交互就不會出現跨域問題了。
第一步，配置 Nodejs 代理服務
module.exports = {
dev: {
// Paths
assetsSubDirectory: 'static',
assetsPublicPath: '/',
proxyTable: {
'/api': {
target: 'http://localhost:9002', // 你請求的第三方接口
changeOrigin: false, // 在本地會創建一個虛擬服務端，然后發送請求的數據，并同時接收請求的數據，這樣服務端和服務端進行數據的交互就不會有跨域問題
pathRewrite: { // 路徑重寫，
'^/api': '' // 替換target中的請求地址，也就是說以后你在請求http://api.codingmore.top/v2/XXXXX這個地址的時候直接寫成/api即可。
}
},
},
}
第二步，配置前端訪問請求路徑
module.exports = merge(prodEnv, {
NODE_ENV: '"development"',
VUE_APP_BASE_API: '"/api"'
// VUE_APP_BASE_API: '"http://localhost:9002"'
})
第三步，重啟前端服務
再次點擊「登錄」按鈕，可以看到請求的 URL 發生了改變，原來是 http://localhost:9002/users/login，現在是 http://localhost:8080/api/users/login。與此同時，可以看到多了一個 Remote Address，端口也是 8080，也就是說經過 Nodejs 的代理，前后端的交互在同一個源下面了，這樣就不會發生跨域問題了。
同時，可以看得到，服務器端返回的狀態碼變成了 200，表示請求成功。
三、開啟跨域資源共享
跨域資源共享，也就是 Cross-Origin Resource Sharing，簡拼為 CORS，是一種基于 HTTP 頭信息的機制，通過允許服務器標識除了它自己以外的資源，從而實現跨域訪問。
第一步，開啟 CORS 支持
在 Spring Boot 應用中，加入 CORS 的支持簡單到不忍直視，添加一個配置類就可以了。
@Configuration
public class GlobalCorsConfig {
@Bean
public CorsFilter corsFilter() {
CorsConfiguration config = new CorsConfiguration();
// 設置你要允許的網站域名
config.addAllowedOrigin("http://localhost:8080");
//允許跨域發送cookie
config.setAllowCredentials(true);
//放行全部原始頭信息
config.addAllowedHeader("*");
//允許所有請求方法跨域調用
config.addAllowedMethod("*");
UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
source.registerCorsConfiguration("/**", config);
return new CorsFilter(source);
}
}
第二步，重啟后端服務，再次點擊登錄按鈕，發現請求已經可以正常訪問了。
本例中，后端返回 Access-Control-Allow-Origin: http://localhost:8080 就表示，跑在 9002 端口下的后端接口可以被 8080 端口的前端請求訪問。
如果允許所有域名進行跨域調用的話，只需改變一行代碼即可。
//允許所有域名進行跨域調用
config.addAllowedOriginPattern("*");
// 設置你要允許的網站域名
// config.addAllowedOrigin("http://localhost:8080");
對于 login 這種簡單的請求來說，它們是不會觸發 CORS 預檢的，因此不需要在服務器端增加其他配置就可以了。那什么是簡單請求呢?
1)請求方法是以下三種方法之一：
- HEAD
- GET
- POST
2)HTTP 的頭信息不超出以下幾種字段：
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type：只限于三個值 application/x-www-form-urlencoded、multipart/form-data、text/plain
那對于會觸發 CORS 預檢的非簡單請求(比如說請求方法是 PUT 或 DELETE，或者 Content-Type 字段的類型是 application/json，或者請求消息頭包含了一些自定義的字段)，該怎么辦呢?
非簡單請求在正式通信之前，會增加一次 HTTP 查詢請求，稱為“預檢”請求。預檢請求通過后，才會返回正常的響應內容。
拿編程貓的文章管理頁來舉例，該頁面會向后端發起一個 posts/queryPageable 的分頁查詢，該請求包含了一個自定義的消息頭 Authorization，于是瀏覽器認為該請求是一個非簡單請求，然后就會自動發起一次 OPTIONS 請求，但由于我們的 Spring Boot 項目整合了 SpringsScurity 安全管理框架，沒有對OPTIONS請求放開登錄認證，導致驗證失敗，文章分頁請求的響應數據就沒有返回回來。
第三步，通過以下代碼給 OPTIONS 請求放行。
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity httpSecurity) throws Exception {
ExpressionUrlAuthorizationConfigurer<HttpSecurity>.ExpressionInterceptUrlRegistry registry = httpSecurity
.authorizeRequests();
//允許跨域請求的OPTIONS請求
registry.antMatchers(HttpMethod.OPTIONS)
.permitAll();
}
}
再次重啟后端服務，重新訪問文章列表接口，發現有響應數據了。
非簡單請求必須首先使用 OPTIONS 請求方法發起一個預檢請求到服務器端，以獲知服務器是否允許該實際請求。"預檢請求“的使用，避免了跨域請求對服務器的用戶數據造成未預期的影響。
我們來通過兩張圖片簡單總結一下預檢請求的整個過程，第一張，發起 OPTIONS 預檢請求：
第二章，發起正式請求：
四、源碼路徑
編程貓后端源碼：
https://github.com/itwanger/coding-more
編程貓后臺管理的前端源碼：
https://github.com/itwanger/codingmore-admin-web
參考鏈接：
跨域：https://segmentfault.com/a/1190000015597029
CORS：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CORS
阮一峰：https://www.ruanyifeng.com/blog/2016/04/cors.html
簡單請求+預檢請求：https://github.com/amandakelake/blog/issues/62
