使用者登入狀態首先，我想告訴大家的是，因為http是無狀態的協議，也就是說，這個協議是無法記錄使用者訪問狀態的，其每次請求都是獨立的無關聯的，一筆是一筆。而我們的**都是設計成多個頁面的，所在頁面跳轉過程中我們需要知道使用者的狀態，尤其是使用者登入的狀態，這樣我們在頁面跳轉後我們才知道是否可以讓使用者有許可權來操作一些功能或是檢視一些資料。
所以，我們每個頁面都需要對使用者的身份進行認證。當然，我們不可能讓使用者在每個頁面上輸入使用者名稱和口令，這會讓使用者覺得我們的**相當的sb。為了實現這一功能，用得最多的技術就是瀏覽器的cookie，我們會把使用者登入的資訊存放在客戶端的cookie裡，這樣，我們每個頁面都從這個cookie裡獲得使用者是否登入的資訊，從而達到記錄狀態，驗證使用者的目的。但是，你真的會用cookie嗎？下面是使用cookie的一些原則。
1）在cookie中，儲存三個東西——使用者名稱，登入序列，登入token。
使用者名稱：明文存放。
登入序列：乙個被md5雜湊過的隨機數，僅當強制使用者輸入口令時更新（如：使用者修改了口令）。
登入token：乙個被md5雜湊過的隨機數，僅乙個登入session內有效，新的登入session會更新它。
2）上述三個東西會存在伺服器上，伺服器的驗證使用者需要驗證客戶端cookie裡的這三個事。
3）這樣的設計會有什麼樣的效果，會有下面的效果，
a）登入token是單例項登入。意思就是乙個使用者只能有乙個登入例項。
b）登入序列是用來做盜用行為檢測的。如果使用者的cookie被盜後，盜用者使用這個cookie訪問**時，我們的系統是以為是合法使用者，然後更新「登入token」，而真正的使用者回來訪問時，系統發現只有「使用者名稱」和「登入序列」相同，但是「登入token」 不對，這樣的話，系統就知道，這個使用者可能出現了被盜用的情況，於是，系統可以清除並更改登入序列和登入token1）修改口令。
2）修改電子郵件。（電子郵件通常用來找回使用者密碼，最好通發郵件或是發手機簡訊的方式修改，或者乾脆就不讓改一一用電子郵件做帳號名）
3）使用者的隱私資訊。
4）使用者消費功能。
找回口令的功能找回口令的功能一定要提供。但是很多朋友並不知道怎麼來設計這個功能。我們有很多找回口令的設計，下面我逐個點評一下。
口令探測防守 最後，再說一下，關於使用者登入，使用第三方的 oauth 和 openid 也不失為乙個很不錯的選擇。
登陸系統的設計
在做乙個管理平台的時候，面向客戶的最開始的第一步就是管理平台的登陸系統，而由於面向的是企業使用者，內網使用者，因此，往往有很多我們預想不到的情況出現，而這些都會去影響著管理平台的體驗，或者會完全中斷掉你的操作 這裡在分析一些做的比較好的平台後，以及結合我們自身可能遇到的情況，對登陸系統進行乙個新的設...
登陸功能（四）
繼續接著第乙個hello django的更新。接下來，做乙個發布會管理系統，根據書中介紹一步一步實現所有功能，本文為第一篇。django pagestitle head middleware django.middleware.security.securitymiddleware django.c...
完成登陸功能
效果展示 登陸功能講解 在sql表中，last lock time表示上次鎖定的時間 當使用者在介面輸入密碼錯誤時，其login fail count次數就會加1 當次數到達3的時候 則會鎖定該使用者 提示使用者5分鐘後再登陸，當使用者登陸成功的時候 就會將其login fail count設為0次...