當(dāng)Web項目前后端分離開發(fā)的時候, 由于域名不一致, 會出現(xiàn)無法請求和無法維持會話的情況

OPTIONS

在前端Ajax請求后臺的時候, 打開控制臺可以看到, 每一次請求之前都會有一次OPTIONS類型的請求
OPTIONS稱為預(yù)檢請求, 通過這個請求, 瀏覽器會告知服務(wù)器,接下來的請求的情況

Access-Control-Request-Method: POST 
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

得到服務(wù)器的回應(yīng)后瀏覽器便知道這次請求是否被允許

OPTIONS的處理

后臺可以在攔截器或過濾器中處理這個請求, 這里以Springboot后臺的攔截器為例

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object o) {
    String method = request.getMethod().toLowerCase();
    response.setHeader("Access-Control-Allow-Origin", "*");
    response.setHeader("Access-Control-Allow-Methods", "GET, POST, OPTIONS, PUT, PATCH, DELETE");
    response.setHeader("Access-Control-Allow-Headers", "X-Requested-With,content-type");
    response.setHeader("Access-Control-Allow-Credentials", "true");
    response.setHeader("Access-Control-Expose-Headers", "TK");
    if (method.equals("options")){
        return false;
    }
    //...
    return true;
}

Access-Control-Allow-Origin 代表允許請求源, 設(shè)置為*或設(shè)置為前端的域名即可解決跨域無法請求的問題例如http://domain
Access-Control-Allow-Methods 表示允許的請求方式

以下兩個特別說明
Access-Control-Allow-Headers 代表允許瀏覽器可以向 服務(wù)器發(fā)送哪些請求頭
Access-Control-Expose-Headers 代表允許瀏覽器可以讀取哪些服務(wù)器發(fā)送的請求頭
均限制在客戶端上

字由https://www./sites/73248.html 中國字體設(shè)計網(wǎng)https://www./sites/73245.html

利用Token保持會話

傳統(tǒng)開發(fā)前后端能維持會話, 是因為當(dāng)服務(wù)器調(diào)用了HttpSession時, 會將SessionId放在請求頭的set-cookie中, 瀏覽器讀取到了這個信息, 就把SessionId保存在本地, 待下次請求時以Cookie的形式帶給服務(wù)器, 服務(wù)器根據(jù)收到的SessionId找到Session 以繼續(xù)會話

現(xiàn)在由于前后端分離后使用Cookie的種種不便, 可以換另一種方式來進行SessionId的傳輸, 就是把SessionId放在請求頭中帶給瀏覽器

接上一段代碼

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object o) {
    //...
    HttpSession session = request.getSession();
    response.setHeader("TK",session.getId());
    return true;
}

由于設(shè)置了response.setHeader("Access-Control-Expose-Headers", "TK");
表示客戶端可以讀取header中的TK字段, 客戶端就可以讀取放在TK中的SessionId保存到本地, 存儲方式可以是Cookie或者是LocalStorage都可以
當(dāng)需要請求時用http://service;jsessionid=${token}的形式傳給服務(wù)器, 這個與傳統(tǒng)Web中Cookie:jsESSIONID=sessionid的形式效果是一致的
如此就達到了保持會話的目的了

為什么能維持會話

服務(wù)器根據(jù)sessionid保持會話這件事是容器完成的, 根據(jù)的就是請求中所傳來的URL后的;jsessionid= 或者 cookie中的jsESSIONID=,
容器根據(jù)sessionid自動找到內(nèi)存中的Session。
這也是選擇;jsessionid=方式的原因。這會讓你沒有感覺像在做前后端分離的開發(fā), 就像傳統(tǒng)的jsP開發(fā)一樣, 前后端融合在一起。

當(dāng)然你也可以用其他方式手動操作, 比如直接傳參 http://service?JID=${token}, 在請求頭中帶過去之類的, 然后手動取得ID再去找對應(yīng)的Session, 不過這就有點多此一舉了