問題描述

問題解答

如果后端是分布式的話（比如云服務器），建議使用 oauth2.0中的token驗證方式，如果只是開發(fā)的話，可以用cookie。oauth登錄流程如下:

新建token表，字段 token,user_id,login_at,expire_at

用戶使用賬號密碼登錄

登錄成功則在數(shù)據(jù)表token插入一條記錄，并把該用戶之前所有token刪除或者設置為過期，并把token返回給前端

前端使用ajax的時候添加headerAuthorization=token

后端讀取請求頭中的Authorization，并與數(shù)據(jù)庫比對，如果存在且未過期，則視為合法用戶，否則返回錯誤

1 用戶登錄一般就是cookie + session，服務器不是同一臺也一樣呀，其中一臺多一個請求轉(zhuǎn)發(fā)功能就好了，因為同源策略的限制，訪問另一個域名是不能帶上cookie的。

2 一般會在前端會有個摘要函數(shù)來生成數(shù)據(jù)的摘要，雖然隨數(shù)據(jù)post上去，然后后端用同樣的摘要函數(shù)生成post上來的數(shù)據(jù)的摘要，與post上來的摘要進行比對，如果一致就證明數(shù)據(jù)沒被修改過。但是用戶如果知道你用的摘要函數(shù)是什么它也可以自己生成數(shù)據(jù)的摘要post上去，所以其實理論上是沒法判斷的，但實際中普通用戶并不知道這些。

JWT, json web token.

后端怎么判斷這個數(shù)據(jù)是否被更改? 什么意思? 后端db不是存了數(shù)據(jù)嗎?

后端數(shù)據(jù)驗證，這個是前后端分離數(shù)據(jù)安全必須要做的。通常的做法就是做sign加密需要用到的是key和secret比如淘寶api的加密方式 淘寶sign

key為用戶標識，表名你是誰，secret代表你的鑰匙。鑰匙為服務端生成，只能在客戶端加密時使用，在數(shù)據(jù)傳輸過程中不能包含sercet信息。客戶端根據(jù)特定規(guī)則對所有請求數(shù)據(jù)進行加密后，后端獲取到所提交的數(shù)據(jù)在用同樣方式加密，然后對比sign參數(shù)是否一致，一致則說明數(shù)據(jù)在傳輸過程中未遭到篡改。另外還需要時間的時效性檢測比如timestamp參數(shù)，要求時間誤差不得超過前后5分鐘還有一點，數(shù)據(jù)重復請求，后端接收到sign后做個cache把sign存起來，失效時間5分鐘（和上面時間對應），同一個sign表示本次請求已經(jīng)重復請求過，然后拒絕

基本上都是這個流程，保證數(shù)據(jù)安全，時效性，防重復等。

sessionStorage或localStorage 保存后臺自己生成的特殊密碼。每次請求通過head帶上，通過后臺驗證數(shù)據(jù)合法