先後端session同步

會話

傳統的web開發採用的通常是會話技術，由於http是一種無狀態協議，服務器端要想肯定不一樣的請求是不是由同一個用戶發出，採用了會話技術，傳統的web開發當中，同一個會話內的全部請求對應着同一個session(session是服務器端爲用戶儲存的文件)，每一個session對應一個id，當用戶第一次訪問時，服務器將這個session_id寫入瀏覽器的cookie中(注意這個cookie比較特殊，通常由瀏覽器貯存在內存裏),因而在會話結束前，以後發送的每次請求中，該cookie中所存的session_id都會被髮送到服務器端，基於這樣的機制，服務器就能夠維持會話中的一些基本信息了。

先後端分離後的會話

在先後端分離以後，數據交互通常採用了json，這種狀況下並不存在cookie和session的交互，爲了維持會話通常會採用token的形式，對於一次會話後端會生成一個獨一無二的token來標識它，每次前端發送數據時帶上這個token，後端就可以識別和維持會話了。可是若是對於全部的會話，尤爲是臨時對話，若是都要生成token來標識，比較難維護。

先後端session同步

綜上，對於臨時對話，後端仍舊能夠採用session的方式來維持（好比驗證圖片驗證碼的場景），可是此時前端發送的請求必須模擬傳統http請求（xxx-form-urlencoded），請求必須帶上cookie來維持session.

實戰

場景：圖片驗證碼的獲取和驗證（兩個接口，兩次請求） 前端：react + fetch 後端：laravel框架

首先前端正常fetch訪問獲取接口，訪問後後端將在cookie中寫入一個session_id(laravel_session)，注意laravel每次的session_id都會變更，所以下一次請求帶的是上一次請求結束時被寫入的cookie

後端此時在對應的session中存儲了驗證碼的字面內容，前端下一次發送請求時，必須保證是和獲取的請求在同一會話中，後端才能同步調用這個session來驗證內容是否正確。所以調用驗證接口時，前端必須模擬傳統請求方式來帶上token

fetch中，將header的Content-Type設置爲xxx-form-urlencoded，body採用get字符串形式(key=val1&key2=val2)，設置成請求帶上cookie的方式來發送，就能成功進入同一個會話。

若是不模擬傳統方式來發送，僅僅帶上cookie，將會產生跨域問題