**
登陸機制可粗略分為三個部分：登陸驗證、登陸保持、登出
登陸驗證：登陸驗證是指客戶端提供使用者名稱和密碼，想伺服器提出登陸請求，伺服器判斷客戶端是否可以登陸並向客戶端確認
登陸保持：是指客戶端登陸後，伺服器能夠分辨出已登陸的使用者，並為其持續提供有登陸許可權的伺服器
登出：是指客戶端主動退出登陸狀態
容易想到的方案是，客戶端登入成功後， 伺服器為其分配sessionid, 客戶端隨後每次請求資源時都帶上sessionid。
**登陸驗證
1、密碼的傳輸
客戶端第一次發出登入請求時， 使用者密碼以明文的方式傳輸， 一旦被截獲， 後果嚴重。因此密碼需要加密，例如可採用rsa非對稱加密。具體流程如下：
2、登陸狀態token
再仔細核對上述流程，發現判斷使用者是否登陸完全依賴於sessionid，一旦被截獲，黑客就能模擬使用者登陸請求，於是我們需要引入token概念，使用者登入成功後， 伺服器不但為其分配了sessionid, 還分配了token， token是維持登入狀態的關鍵秘密資料。在伺服器向客戶端傳送的token資料，也需要加密。於是一次登入的細節再次擴充套件。
登陸保持
在最原始的方案中， 登入保持僅僅靠伺服器生成的sessionid: 客戶端的請求中帶上sessionid, 如果伺服器的redis中存在這個id，就認為請求來自相應的登入客戶端。 但是只要sessionid被截獲， 請求就可以為偽造， 存在安全隱患。
引入token後，上述問題便可得到解決。 伺服器將token和其它的一些變數， 利用雜湊加密演算法得到簽名後，連同sessionid一併傳送給伺服器； 伺服器取出儲存於伺服器端的token,利用相同的法則生成校驗簽名， 如果客戶端簽名與伺服器的校驗簽名一致， 就認為請求來自登入的客戶端。
登出token失效
使用者登入出系統
失效原理：
在伺服器端的redis中刪除相應key為session的鍵值對。
登陸驗證機制
做過web開發的程式設計師應該對session都比較熟悉，session是一塊儲存在伺服器端的記憶體空間，一般用於儲存使用者的會話資訊。使用者通過使用者名稱和密碼登陸成功之後，伺服器端程式會在伺服器端開闢一塊session記憶體空間並將使用者的資訊存入這塊空間，同時伺服器會 在cookie中寫入乙個...
登陸現象詳解
現象1 當登陸以後，如果繼續重新整理頁面，次數還會不斷的增加。現象2 如果後退，那麼會顯示出登陸框。此時重新整理，會顯示登陸資訊。tile.jsp boolean isflag false isflag 1 equals session.getattribute flag if isflag els...
uchome登陸機制分析（一）
uchome root 為uchome的根目錄 第一步 定位到uchome root source do login.php,找到如下函式 php 上示函式便是登陸的第一步處理函式,再次定位 uchome root source function common.php,找到如下函式 php 至此,我...