【判斷使用者登入】PHP這樣判斷流程是否正確？每次都查詢資料庫 存COOKIE

我自己來做的PHP判斷使用者是否登入：

【流程】
1 先判斷有沒有cookie('uid') && cookie('uid') 如果沒有跳出迴圈檢測
2 如果有，串連資料庫查詢該uid對應的記錄，如果沒有改記錄則跳出迴圈檢測並且登出所有使用者cookie
3 如果有，檢測cookie('upwd')== md5($rs[pwd].cookie('salt'))，如果不相等，提示密碼發生修改需要重新登入
4 如果相等，檢測cookie('email') == md5($rs[email])，如果不相等，提示郵箱發生更改，需要重新登入
5 如果相等 => 正確，該使用者是當前登入使用者。

但是！
【問題】
1 每次都要串連資料庫，減少資料庫查詢是使用者最佳化的關鍵，如果每次都去資料庫查詢，真的會影響效能。
2 如何最佳化才最好，這個登入判斷流程是否有誤。

【另外一種思路】
1 存放到SESSION，儲存$uid,$uname,$lastactive（最後回應時間）到session中。
2 如果有session('uid') && session('uname') 檢測time()-$lastactive > 3600 ，那麼串連資料庫查詢（如上面的cookie判斷），否則直接用（session存放位置php.ini預設配置的位置）

【問題】
1 如果存放到SESSION中，那麼高並發的情況下，是否會受影響？

回複討論(解決方案)

當採用第二種方案時你顧慮高並發的情況
那麼採用第一種方案就可不考慮高並發的情況了嗎？

在你的第一方案中，使用者的口令和Email都放在cookie中，這些資料總是在網路中跑來跑去，你認為很安全嗎？

資料庫應該是廣義的
雖然基於檔案系統的關係型資料庫（SQL）速度可能稍有遜色，但他們都提供有基於記憶體的記憶體表
何況資料庫還有另一分支：基於記憶體的noSQL
所以資料庫查詢帶來的額外開銷是可以忽略不計的

判斷使用者是否登入的流程是：
如果 cookie('uid') 不存在 轉要求登入處理
否則查詢資料庫，檢查該 uid 上次登入地點是否與本次相同：
相同則確認
不同則發出提示，有條件轉要求登入處理

當採用第二種方案時你顧慮高並發的情況
那麼採用第一種方案就可不考慮高並發的情況了嗎？

在你的第一方案中，使用者的口令和Email都放在cookie中，這些資料總是在網路中跑來跑去，你認為很安全嗎？

資料庫應該是廣義的
雖然基於檔案系統的關係型資料庫（SQL）速度可能稍有遜色，但他們都提供有基於記憶體的記憶體表
何況資料庫還有另一分支：基於記憶體的noSQL
所以資料庫查詢帶來的額外開銷是可以忽略不計的

判斷使用者是否登入的流程是：
如果 cookie('uid') 不存在 轉要求登入處理
否則查詢資料庫，檢查該 uid 上次登入地點是否與本次相同：
相同則確認
不同則發出提示，有條件轉要求登入處理

那每次都要查詢MYSQL資料庫了。根據登入地址，一般來說是IP了。

檢查使用者來源，是為了防止 CSRF攻擊
一般只在用寫動作的頁面進行

我的做法是這樣的。
1.使用者login，串連資料庫判斷是否成功，如成功後把使用者id，使用者name等需要用到判斷的資訊，寫入session和cookies，cookies設定一個時間（例如1天~2周，這個登入時給使用者自己選擇），另外，我是把存入cookies的資料做一個json_encode，然後加密處理。
例如 {"uid":1,"username":"fdipzone"} 加密成可逆的字串。

2.當使用者訪問時，會有以下幾種情況
1.判斷session是否存在->是->通過
2.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是->把cookies寫入session->通過
3.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->否->跳轉到login頁面
4.判斷session是否存在->否->判斷cookies是否存在->否->跳轉到login頁面

我的做法是這樣的。
1.使用者login，串連資料庫判斷是否成功，如成功後把使用者id，使用者name等需要用到判斷的資訊，寫入session和cookies，cookies設定一個時間（例如1天~2周，這個登入時給使用者自己選擇），另外，我是把存入cookies的資料做一個json_encode，然後加密處理。
例如 {"uid":1,"username":"fdipzone"} 加密成可逆的字串。

2.當使用者訪問時，會有以下幾種情況
1.判斷session是否存在->是->通過
2.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是->把cookies寫入session->通過
3.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->否->跳轉到login頁面
4.判斷session是否存在->否->判斷cookies是否存在->否->跳轉到login頁面

你的流程貌似沒有查詢過資料庫，很節約，但是存在漏洞問題：
1 假如帳號在11點正常登入，12點帳號被盜，密碼被修改。可他還可以繼續使用帳號，和那個盜號者一起共同使用
2 假設使用者密碼已經發生修改，可他沒有退出重新登入卻可以繼續使用該帳號
3 更關鍵的不可控，假設使用者在11點登陸，12點管理員封鎖其帳號，可他卻還是可以繼續使用，除非他退出重新登入一次。

我的做法是這樣的。
1.使用者login，串連資料庫判斷是否成功，如成功後把使用者id，使用者name等需要用到判斷的資訊，寫入session和cookies，cookies設定一個時間（例如1天~2周，這個登入時給使用者自己選擇），另外，我是把存入cookies的資料做一個json_encode，然後加密處理。
例如 {"uid":1,"username":"fdipzone"} 加密成可逆的字串。

2.當使用者訪問時，會有以下幾種情況
1.判斷session是否存在->是->通過
2.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是->把cookies寫入session->通過
3.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->否->跳轉到login頁面
4.判斷session是否存在->否->判斷cookies是否存在->否->跳轉到login頁面

你的流程貌似沒有查詢過資料庫，很節約，但是存在漏洞問題：
1 假如帳號在11點正常登入，12點帳號被盜，密碼被修改。可他還可以繼續使用帳號，和那個盜號者一起共同使用
2 假設使用者密碼已經發生修改，可他沒有退出重新登入卻可以繼續使用該帳號
3 更關鍵的不可控，假設使用者在11點登陸，12點管理員封鎖其帳號，可他卻還是可以繼續使用，除非他退出重新登入一次。

我判斷closeuser的部分在login之後進行。因為如果前面的步驟都不成功，就不需要調用closeuser判斷了。

對了，有個位置漏說了，當session到期，然後把cookies寫入session時。我會把這次操作的時間記錄入db，作為使用者的最後線上時間的。當判斷上一次的最後線上時間比現在的超過10分鐘，我會check一次closeuser的表，判斷是否被屏蔽。如果被屏蔽，就跳到對應的資訊提示頁面。就是每10分鐘會檢查一次db吧。
判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是-> 把cookies寫入session->通過

然後，每10分鐘，檢查一次

我的做法是這樣的。
1.使用者login，串連資料庫判斷是否成功，如成功後把使用者id，使用者name等需要用到判斷的資訊，寫入session和cookies，cookies設定一個時間（例如1天~2周，這個登入時給使用者自己選擇），另外，我是把存入cookies的資料做一個json_encode，然後加密處理。
例如 {"uid":1,"username":"fdipzone"} 加密成可逆的字串。

2.當使用者訪問時，會有以下幾種情況
1.判斷session是否存在->是->通過
2.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是->把cookies寫入session->通過
3.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->否->跳轉到login頁面
4.判斷session是否存在->否->判斷cookies是否存在->否->跳轉到login頁面

你的流程貌似沒有查詢過資料庫，很節約，但是存在漏洞問題：
1 假如帳號在11點正常登入，12點帳號被盜，密碼被修改。可他還可以繼續使用帳號，和那個盜號者一起共同使用
2 假設使用者密碼已經發生修改，可他沒有退出重新登入卻可以繼續使用該帳號
3 更關鍵的不可控，假設使用者在11點登陸，12點管理員封鎖其帳號，可他卻還是可以繼續使用，除非他退出重新登入一次。

第1點 其實是 假如使用者在網吧或其他地區登入忘了退出，之後別人使用那台上網裝置就可以操作他帳號的內容，即使使用者回到家裡修改密碼也無濟於事，除非那邊退出重新登入（包括關機/重啟/徹底關閉瀏覽器進程）。

我的做法是這樣的。
1.使用者login，串連資料庫判斷是否成功，如成功後把使用者id，使用者name等需要用到判斷的資訊，寫入session和cookies，cookies設定一個時間（例如1天~2周，這個登入時給使用者自己選擇），另外，我是把存入cookies的資料做一個json_encode，然後加密處理。
例如 {"uid":1,"username":"fdipzone"} 加密成可逆的字串。

2.當使用者訪問時，會有以下幾種情況
1.判斷session是否存在->是->通過
2.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是->把cookies寫入session->通過
3.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->否->跳轉到login頁面
4.判斷session是否存在->否->判斷cookies是否存在->否->跳轉到login頁面

你的流程貌似沒有查詢過資料庫，很節約，但是存在漏洞問題：
1 假如帳號在11點正常登入，12點帳號被盜，密碼被修改。可他還可以繼續使用帳號，和那個盜號者一起共同使用
2 假設使用者密碼已經發生修改，可他沒有退出重新登入卻可以繼續使用該帳號
3 更關鍵的不可控，假設使用者在11點登陸，12點管理員封鎖其帳號，可他卻還是可以繼續使用，除非他退出重新登入一次。

我判斷closeuser的部分在login之後進行。因為如果前面的步驟都不成功，就不需要調用closeuser判斷了。

對了，有個位置漏說了，當session到期，然後把cookies寫入session時。我會把這次操作的時間記錄入db，作為使用者的最後線上時間的。當判斷上一次的最後線上時間比現在的超過10分鐘，我會check一次closeuser的表，判斷是否被屏蔽。如果被屏蔽，就跳到對應的資訊提示頁面。就是每10分鐘會檢查一次db吧。
判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是-> 把cookies寫入session->通過

然後，每10分鐘，檢查一次

如果用session存放資訊，當關閉瀏覽器（包括強制關閉瀏覽器進程），那麼是不是session就到期了

更正一下。
當session到期，把cookies寫入session時。在這個位置會連資料庫判斷使用者是否被禁止登入。
session有自己的到期時間，所以，每次連資料庫檢查的時間間隔就是session的生命週期。

判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是-> 檢查是否禁止登入->否->把cookies寫入session->通過

判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是-> 檢查是否禁止登入->是->清除使用者cookies->跳轉到通知頁面

我的做法是這樣的。
1.使用者login，串連資料庫判斷是否成功，如成功後把使用者id，使用者name等需要用到判斷的資訊，寫入session和cookies，cookies設定一個時間（例如1天~2周，這個登入時給使用者自己選擇），另外，我是把存入cookies的資料做一個json_encode，然後加密處理。
例如 {"uid":1,"username":"fdipzone"} 加密成可逆的字串。

2.當使用者訪問時，會有以下幾種情況
1.判斷session是否存在->是->通過
2.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是->把cookies寫入session->通過
3.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->否->跳轉到login頁面
4.判斷session是否存在->否->判斷cookies是否存在->否->跳轉到login頁面

你的流程貌似沒有查詢過資料庫，很節約，但是存在漏洞問題：
1 假如帳號在11點正常登入，12點帳號被盜，密碼被修改。可他還可以繼續使用帳號，和那個盜號者一起共同使用
2 假設使用者密碼已經發生修改，可他沒有退出重新登入卻可以繼續使用該帳號
3 更關鍵的不可控，假設使用者在11點登陸，12點管理員封鎖其帳號，可他卻還是可以繼續使用，除非他退出重新登入一次。

我判斷closeuser的部分在login之後進行。因為如果前面的步驟都不成功，就不需要調用closeuser判斷了。

對了，有個位置漏說了，當session到期，然後把cookies寫入session時。我會把這次操作的時間記錄入db，作為使用者的最後線上時間的。當判斷上一次的最後線上時間比現在的超過10分鐘，我會check一次closeuser的表，判斷是否被屏蔽。如果被屏蔽，就跳到對應的資訊提示頁面。就是每10分鐘會檢查一次db吧。
判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是-> 把cookies寫入session->通過

然後，每10分鐘，檢查一次

如果用session存放資訊，當關閉瀏覽器（包括強制關閉瀏覽器進程），那麼是不是session就到期了

是的，那麼就會執行判斷cookies的事件了。

更正一下。
當session到期，把cookies寫入session時。在這個位置會連資料庫判斷使用者是否被禁止登入。
session有自己的到期時間，所以，每次連資料庫檢查的時間間隔就是session的生命週期。

判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是-> 檢查是否禁止登入->否->把cookies寫入session->通過

判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是-> 檢查是否禁止登入->是->清除使用者cookies->跳轉到通知頁面

如果是這樣，貌似不用再SESSION了吧。
不過關閉瀏覽器就session到期真的不可思議啊。。。

更正一下。
當session到期，把cookies寫入session時。在這個位置會連資料庫判斷使用者是否被禁止登入。
session有自己的到期時間，所以，每次連資料庫檢查的時間間隔就是session的生命週期。

判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是-> 檢查是否禁止登入->否->把cookies寫入session->通過

判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是-> 檢查是否禁止登入->是->清除使用者cookies->跳轉到通知頁面

如果是這樣，貌似不用再SESSION了吧。
不過關閉瀏覽器就session到期真的不可思議啊。。。

session是會話進程，關閉會話消失很正常。
session其實也是cookie，只不過存活時間比較短，但是相較於cookie直接使用更安全，用戶端只儲存一個sessionid的cookie值，其他內容儲存在伺服器上，使用者瀏覽時通過sessionid讀取session的內容。

類似html5的 localStorage 和 sessionStorage

我的做法是這樣的。
1.使用者login，串連資料庫判斷是否成功，如成功後把使用者id，使用者name等需要用到判斷的資訊，寫入session和cookies，cookies設定一個時間（例如1天~2周，這個登入時給使用者自己選擇），另外，我是把存入cookies的資料做一個json_encode，然後加密處理。
例如 {"uid":1,"username":"fdipzone"} 加密成可逆的字串。

2.當使用者訪問時，會有以下幾種情況
1.判斷session是否存在->是->通過
2.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是->把cookies寫入session->通過
3.判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->否->跳轉到login頁面
4.判斷session是否存在->否->判斷cookies是否存在->否->跳轉到login頁面

你的流程貌似沒有查詢過資料庫，很節約，但是存在漏洞問題：
1 假如帳號在11點正常登入，12點帳號被盜，密碼被修改。可他還可以繼續使用帳號，和那個盜號者一起共同使用
2 假設使用者密碼已經發生修改，可他沒有退出重新登入卻可以繼續使用該帳號
3 更關鍵的不可控，假設使用者在11點登陸，12點管理員封鎖其帳號，可他卻還是可以繼續使用，除非他退出重新登入一次。

我判斷closeuser的部分在login之後進行。因為如果前面的步驟都不成功，就不需要調用closeuser判斷了。

對了，有個位置漏說了，當session到期，然後把cookies寫入session時。我會把這次操作的時間記錄入db，作為使用者的最後線上時間的。當判斷上一次的最後線上時間比現在的超過10分鐘，我會check一次closeuser的表，判斷是否被屏蔽。如果被屏蔽，就跳到對應的資訊提示頁面。就是每10分鐘會檢查一次db吧。
判斷session是否存在->否->判斷cookies是否存在->是->判斷cookies解密是否成功->是-> 把cookies寫入session->通過

然後，每10分鐘，檢查一次

如果使用者一直在操作頁面 那SESSION設定了逾時時間，到了時間 會失效嗎？

