在幾年以前，只要你掌握PHP，你就能編寫一個自己的博客，這個時候，前端僅僅是作爲Web項目的View層存在的。隨着前端功能越來越複雜化以及手機APP的產生，前後端完全分離成爲趨勢，前端成爲了一個完整的“客戶端”，有了自己的MVVM（Model-View-ViewModel）框架，而後端則變爲API可以同時提供給H5和APP。前後端分離後可能會部署在兩個不同的服務器，從而導致協議、域名、端口不同。而變化往往就導致問題發生。
問題1：爲什麼Ajax請求發送總是失敗？
這是因爲瀏覽器有同源策略，所謂同源策略就是不同協議、域名、端口間不能共享cookie，操作dom，有限地發送ajax請求。同源策略已經存在了幾十年了，其意義也比較好理解，假設你在銀行網站獲得了一個cookie，如果沒有同源策略，那麼惡意網站可以獲得你從銀行網站獲得的cookie，從而僞裝成你，登錄到銀行網站獲得你的財產。至於怎麼讓你打開惡意網站鏈接，可以給你發送一封帶url的鏈接，也可以微信QQ等，由於惡意行爲是後臺進行的，而你看到的就是個正常的頁面。
瀏覽器對於跨域請求有兩種允許方式。
1.簡單請求
滿足以下兩個條件的爲簡單請求：
a.請求方法只能爲HEAD、GET、POST中的一種。
b.請求頭中的字段只能有以下5個：Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type，其中，Content-Type只能爲application/x-www-form-urlencode、multipart/form-data、text\plain中的一個。
這是爲了兼容傳統跨域表單，即，原先可以使用表單發送的，ajax也同樣可以。
當請求發送時，瀏覽器會在請求頭中添加Origin字段，標明該請求是由哪個源（協議 + 域名 + 端口）發送的。如果服務器的響應頭中沒有Access-Control-Allow-Origin字段，或Access-Control-Allow-Origin字段中不包含頁面的源，那麼，本次請求失敗。
2.非簡單請求
不滿足簡單請求條件的都是非簡單請求。
在發送正式的請求前，瀏覽器會給服務器發送一個OPTIONS請求，如果正式的請求不能滿足服務器響應頭中的條件，即Access-Control-Allow-Origin包含本頁面的源，正式請求的請求方法滿足Access-Control-Allow-Method，正式請求的請求頭中的額外字段在Access-Control-Allow-Headers之中，那麼，本次請求失敗。
那麼解決方式就顯而易見了，我們需要對後端的intercepter進行改造
1.在響應頭中添加：
Access-Control-Allow-Origin:請求的Origin
Access-Control-Allow-Method:GET,POST
Access-Control-Allow-Headers:Authorization
2.後端判斷請求是不是OPTIONS請求，如果是，則直接渲染空的請求體返回。
問題2：用戶身份認證怎麼辦？
根據第一個問題，我們可以知道瀏覽器有同源策略，頁面不能訪問不同源下的Cookie，這就導致原先的Cookie-Session的用戶身份認證機制無法工作。
對於這種情況，我們在請求頭中使用Authorization字段來代替Cookie中的JSESSIONID（以jetty例），構成Token-Session機制。使用JWT（JSON Web Token）作爲Token的生成方式。
Authorization:bearer Token
JWT生成的Token分爲三個部分，每個部分使用“.”分隔。
JWT頭存放了簽名的加密方式
有效載荷存放身份有關的不敏感信息以及發佈時間過期時間，例如，user_id，client_id，exp，iat
簽名部分根據前兩部分和服務器私鑰計算得出，用於校驗Token的有效性
當用戶登錄時，如果登錄成功，後端返回Token，前端把Token存放在localstorage中，以後每次發送請求時，都在請求頭中附帶Authorization:bearer Token，後端收到時，使用私鑰校驗Token的正確性，如果Token正確，則解碼有效載荷中的user_id到session中獲取數據，
參考資料：
http://www.ruanyifeng.com/blog/2016/04/cors.html
http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html
https://baijiahao.baidu.com/s?id=1608021814182894637&wfr=spider&for=pc