參考：
跨域是網路安全領域的乙個專有名詞。簡單點理解就是某些操作越過了網域名稱的界限，訪問了別的網域名稱。如果指令碼可以自由訪問其他域，就會產生很多安全問題。
什麼情況下會跨域？ 不同協議、不同網域名稱、不同埠、不同主機。
什麼情況不是跨域？ 滿足網域名稱、協議、埠均相同的即不是跨域。
解決方案：
1、jsonp（不推薦）
最初用來解決跨域問題的方式，叫做jsonp，它的基本原理是：跨域的「資源嵌入」是被瀏覽器允許的。所以，可以通過乙個script標籤來嵌入一段來自其他伺服器的指令碼。由於這個指令碼完全執行在當前域，無法訪問第三方伺服器的cookie等敏感資訊，所以是安全的。
jsonp的缺點是它只能支援get操作，沒法支援post等操作，但是由於相容性好等優點，仍然有很多**採用jsonp的方式公開自己的api供第三方呼叫。
2、反向**
要想解決跨域問題，最簡單徹底的方法當然是把他們拉到乙個域下，而這就是該「反向**」發揮作用的時候了。
所謂反向**，就是在自己的網域名稱下架設乙個web伺服器，這個伺服器會把請求**給第三方伺服器，然後把結果返回給客戶端。這時候，在客戶端看來，自己就是在和這台反向**伺服器打交道，而不知道第三方伺服器的存在。
所以，如果有乙個web服務程式，它同時提供了反向**功能和靜態檔案服務功能，靜態檔案服務負責渲染前端頁面，反向**則提供對第三方伺服器的透明訪問。那麼前端和後端就變成了同源的，不再受同源策略的約束。
那麼，有這樣的web服務程式嗎？有，而且不止乙個。事實上，幾乎所有的主流web伺服器都提供了反向**功能。這裡僅以nginx為例來示範反向**的配置方式，其他web伺服器請搜相應的文件自行研究。
server
location /api/
}
/service，而前端使用的路徑是/api，那麼前端將不能訪問後端的cookie，這就導致登入等操作所寫入的cookie無法正常傳入傳出，其表現則是登入始終沒有效果。cookie的domain機制也是類似的原理。
現實中的後端伺服器，使用path機制的很多，所以這項設定非常實用。
server
location /apis
}
這是w3c提供的另一種跨域方式。它定義了在跨域訪問資源時瀏覽器和伺服器之間如何通訊。cors背後的基本思想是使用自定義的http頭部允許瀏覽器和伺服器相互了解對方，從而決定請求或響應成功與否。
作為一項標準的跨域規範，cors本應該是最值得採用的。 問題在於，老式瀏覽器不支援cors，而我們顯然還沒到可以無視老式瀏覽器的時候。 所以，只要有可能，就應該優先採用反向**的方式。
cors的原理是基於服務方授權的模式，也就是說提供服務的程式要主動通過cors回應頭來宣告自己信任哪些源（協議+網域名稱+埠）。 由於得到了服務方的授權，瀏覽器就可以放行來自這些域的請求了。
前後端分離跨域問題
access to xmlhttprequest at localhost 8081 user gettoken?username hyly password hyly from origin http localhost 63342 has been blocked by cors policy ...
前後端分離跨域問題
public class loginhandlerinterceptor implements handlerinterceptor response.sendredirect request.getcontextpath login.html catch ioexception e return ...
前後端分離專案解決跨域問題
後台我使用的ssm框架搭建，前端使用vue cli腳手架完成。最開始我在後台寫了過濾器，但是前端請求資料的時候，能夠成功請求，可是在返回的時候報了如下錯誤 經過一番研究後，發現在前端其實就可以處理跨域的問題。步驟如下 在vue專案下的config資料夾下的 index.js 檔案中設定 var ur...