PHP網站中保持登錄狀態的功能是怎麼做的？
大多數網站在用戶登錄時會提供一個「記住我」或者「保持登錄狀態」的選項，我只知道是用Cookie實現的，但是具體來說的工作流程是什麼？因為要實現一個網站登錄的東西，所以想從細節方面了解這個問題。
我來談談這個問題吧首先，基於以上幾位朋友提到的，SESSION信息存儲在服務端，相對於存儲在客戶端的COOKIE更為安全，所以正常一般網站在用於「判斷用戶是否登錄」時，確實是使用SESSION，例如可以在SESSION里存儲如下一個數組
//驗證用戶名和密碼成功後
$_SESSION["userinfo"] = [
"uid" =&> 123,
"username" =&> "testuser"
];
而後在需要驗證登錄的地方加入類似如下判斷
if(empty($_SESSION["userinfo"]) || empty($_SESSION["userinfo"]["uid"])){
//未登錄，引導登錄
}
以上是使用SESSION做用戶登錄的基本存儲和驗證邏輯，當然實際開發過程中會將這部分的代碼封裝
我們都知道，SESSION一般是通過在COOKIE里記錄一個KEY為PHPSESSID的COOKIE來保持上下文的，而這個PHPSESSID的COOKIE的有效期是設置為「會話」，意味著關閉瀏覽器後該COOKIE被銷毀，相應的後端SESSION也就銷毀，如圖
而題主關注的是如何實現這個「記住我」的功能，首先，雖然COOKIE保存在客戶端，不安全，易被偽造，這是客觀存在的事實，但要實現這個「記住我」，還確實就得用到COOKIE，我們能做的是盡量去提高偽造的門檻。
這邊僅提供一個參考的設計方案，1、將用戶信息，比如一個["uid"=&>123, "username"=&>"testuser"]的數組，序列化後成為字元串，使用可逆加密演算法加密該字元串，寫到一個Key為userinfo的COOKIE里2、由於可逆加密演算法容易被解密，一旦加密的規則被別人猜測到以後，就可以輕易篡改這個COOKIE的內容，然後自行根據加密規則加密後偽造，所以，我們另外加入一個infodig的COOKIE，是將以上的userinfo的COOKIE內容，加入salt後使用不可逆加密演算法生成散列，至於salt咱們可以自己定，總之要對外保密，不可逆演算法例如md5，甚至多次加鹽多次md53、以上兩個COOKIE，為增強安全性，防止用戶被XSS攻擊後拿到，可以設置http-only屬性服務端判斷存在以上兩個COOKIE後
1、驗證infodig與userinfo是否匹配（將userinfo的內容使用生成infodig的方法計算後，與COOKIE傳上來的infodig匹配是否一致）
2、infodig驗證通過後，使用解密演算法解密userinfo串，得到用戶信息，如果用戶信息里的uid存在用戶表中，則寫SESSION，通過SESSION保持本次會話總而言之，使用COOKIE記錄用戶信息是可行的（當然不建議把用戶敏感的東西存在COOKIE，例如郵箱、手機、甚至密碼，只記錄對登錄有用的部分，例如uid、username等標識，以及nickname可能會在某些地方提升用戶體驗），可以確定的是，這個COOKIE對用戶可見，我們要做的就是兩點：1、盡量讓用戶看不懂，而只有我們服務端自己認識（可逆加密演算法）； 2、即使用戶看懂了，他也不能夠輕易的偽造（不可逆的散列演算法）
以上，儘力表達，希望對題主有幫助，歡迎點贊^_^b先說說結論：
1.cookie和session都可以用來保持登錄狀態。2.如果使用cookie，用於保存用戶狀態的cookie需要加密，並且可被識別，但不必須可以解密。這個意思就是說，加密後的存儲了用戶登錄信息的cookie數據在服務端可被還原，即使不能還原也要可以用於識別和比對（即唯一），php的加密函數可以去網上找，一搜一大把。3.如果使用session，在不考慮安全的情況下，可以簡單的使用$_SESSION這個全局數組達到目的，但是如果需要更高的安全性，需要額外的參數進行安全性驗證，可以是加密字元串也可以是某串數據的MD5指紋。4.使用session可以保證登錄數據的一致性，如果登錄數據中有在登錄時間內可能會發生變動的項目，但是依然需要用到額外的參數去提取原來的session數據。
5.cookie比起session會有個滯後性，這一點需要注意，有時候有益，有時候也不方便。6.在完全理解session的工作機制後，可以嘗試拋棄php本身的session機制，建立自定義session機制。終極結論：
為了保證安全性，既然都需要加密cookie，那麼，為什麼不把用戶登錄數據都存儲在cookie里呢？session還會浪費伺服器端存儲。終極進階結論：
當你學會使用內存資料庫的時候，比如memcached或者redis之類的，cookie和它們結合才是絕佳的解決方案。下面扯點別的：
說起狀態維持這件事情，一直是http的痛處，因為http是無狀態協議，要讓無狀態協議支持狀態維持，於是產生了cookie，早期瀏覽器對cookie戒心甚大，於是勉為其難用一下GET參數也是無妨，現代瀏覽器都是默認開啟cookie的，甚至大部分都已經支持了瀏覽器端存儲（storage）以及少部分支持了瀏覽器端資料庫，後兩者僅是存儲，在請求時並不會向伺服器反饋數據。而session是建立在cookie或者其他從瀏覽器傳回的數據之上的，脫離了cookie或者其他從瀏覽器傳回的參數（比如GET參數）就是無源之水、無根之木。
有人說，甚至有不少人說，session比cookie安全，我覺得這是不恰當的看法。cookie和session具有同等的安全性，並不會因為cookie存儲於客戶端而session存儲於服務端而使cookie的安全性低於session，可以這麼說，cookie和session的安全性都取決於cookie或者前文提到的傳回伺服器的參數的安全性。而且session也不僅僅是局限於php本身提供的session庫，任何存儲於伺服器端的數據都有可能扮演session的角色，本質上session是一種特殊的資料庫，只不過這個資料庫只允許已被識別的唯一合法客戶端去訪問。
雖然我在上面一段文字中強調了唯一，但是識別過程並不可靠，也就是有可能不唯一，這就是所謂的不安全性的來源。事實上，自從網路誕生以來，其上一直充斥的欺騙與暴力。這世上沒有任何事情是唯一的，就像沒有任何事物是完全相同的，雖然哲學一直教導我們世界上沒有兩件完全一樣的事物，也沒有兩件完全獨立的事物，但是這種絕對的觀念並不適合相對的生活。生活中，存在唯一這個概念，然而令人遺憾的是並沒有唯一的事實。即使有個枕邊人溫言細語的告訴你，你是他的唯一，如果你真信了，那隻能是你太天真。唯一這個事情是有分辨粒度的，在可被識別的範圍內，唯一才是有意義的，但是這種有意義卻著實令人心碎，可識別意味著判斷一個事物是否唯一的規則是有限的，有限就意味著可仿冒，時至今日，人類創造了各種用於識別唯一性的技術，但是關於識別技術，卻依然在發展，而且永無止境。最後的最後，附贈幾段cookie操作函數：
特性1：去除了cookie的延時性，即設即用。特性2：可以很方便的在cookie中存儲數組，不需要一條條的寫setcookie語句。特性3：支持「.」索引，比如test.aaaa.bbbb是指cookie里的test[aaaa][bbbb]。注意1：千萬小心cookie的4kb限制，雖然有的現代瀏覽器可能擴充了這個限制。注意2：cookie里存太多東西畢竟增加了網路數據傳輸以及伺服器的數據處理。function set_cookie($data,$path = "/",$time = 0,$doma = NULL)
{
if(!is_array($data))
{
$para = func_get_args();
$data = array($para[0] =&> $para[1]);
$path = isset($para[2]) ? $para[2] : "/";
$time = isset($para[3]) ? $para[3] : 0;
$doma = isset($para[4]) ? $para[4] : NULL;
}
if(is_int($path))
{
$time = $path;
$path = "/";
}
if(is_string($time))
{
$doma = $time;
$time = 0;
}
$time = $time == 0 ? $time : time()+$time;
foreach($data as $key =&> $value)
{
if(!is_array($value))
{
if(strpos($key,".") === FALSE)
{
if(isset($_COOKIE[$key]))
{
if(is_array($_COOKIE[$key]))
{
$cookie_str = http_build_query(array($key =&> $_COOKIE[$key]));
$cookie_arr = explode("",$cookie_str);
foreach($cookie_arr as $cookie)
{
$a_cookie = explode("=",$cookie);
setcookie(urldecode($a_cookie[0]),NULL,-1,$path,$doma);
}
$_COOKIE[$key] = NULL;
}
}
setcookie($key,$value,$time,$path,$doma);
$_COOKIE[$key] = $value;
}
else
{
$cop = $_COOKIE;
$cox = substr_count($key,".");
foreach(explode(".",$key) as $ckk =&> $ckey)
{
if($ckk &> 0)
{
$cookie_key .= "[".$ckey."]";
}
else
{
$cookie_key = $ckey;
}
if($ckk &< $cox)
{
if(isset($cop[$ckey]))
{
if(!is_array($cop[$ckey]))
{
setcookie($cookie_key,NULL,-1,$path,$doma);
$cop[$ckey] = NULL;
}
}
else
{
$cop[$ckey] = NULL;
}
$cop = $cop[$ckey];
}
else
{
if(isset($cop[$ckey]))
{
if(is_array($cop[$ckey]))
{
$cookie_str = http_build_query(array($cookie_key =&> $cop[$ckey]));
$cookie_arr = explode("",$cookie_str);
foreach($cookie_arr as $cookie)
{
$a_cookie = explode("=",$cookie);
setcookie(urldecode($a_cookie[0]),NULL,-1,$path,$doma);
}
$cop[$ckey] = NULL;
}
}
else
{
$cop[$ckey] = NULL;
}
$cop = $cop[$ckey];
}
}
setcookie($cookie_key,$value,$time,$path,$doma);
$cop = $value;
}
}
else
{
$x_cookie_str = http_build_query($value);
$x_cookie_arr = explode("",$x_cookie_str);
foreach($x_cookie_arr as $x_cookie)
{
$a_cookie = explode("=",$x_cookie);
if(isset($a_cookie[1]))
{
set_cookie($key.".".str_replace(array("[","]"),array(".",""),urldecode($a_cookie[0])),urldecode($a_cookie[1]),$time,$path,$doma);
}
}
}
}
}
function cookie($key = NULL,$def = FALSE)
{
if(!empty($key))
{
if(strpos($key,".") === FALSE)
{
if(isset($_COOKIE[$key]))
{
return $_COOKIE[$key];
}
else
{
return $def;
}
}
else
{
$cop = $_COOKIE;
foreach(explode(".",$key) as $ckey)
{
if(isset($cop[$ckey]))
{
$cop = $cop[$ckey];
}
else
{
return $def;
}
}
return $cop;
}
}
else
{
return $_COOKIE;
}
}
function unset_cookie($key = NULL,$path = "/",$doma = NULL)
{
if(!empty($key))
{
if(strpos($key,".") === FALSE)
{
if(isset($_COOKIE[$key]))
{
if(!is_array($_COOKIE[$key]))
{
setcookie($key,NULL,-1,$path,$doma);
}
else
{
$cookie_str = http_build_query(array($key =&> $_COOKIE[$key]));
$cookie_arr = explode("",$cookie_str);
foreach($cookie_arr as $cookie)
{
$a_cookie = explode("=",$cookie);
setcookie(urldecode($a_cookie[0]),NULL,-1,$path,$doma);
}
}
unset($_COOKIE[$key]);
}
}
else
{
$cop = $_COOKIE;
$ckeys = explode(".",$key);
$pop_ckey = array_pop($ckeys);
foreach($ckeys as $ckk =&> $ckey)
{
if($ckk &> 0)
{
$cookie_key .= "[".$ckey."]";
}
else
{
$cookie_key = $ckey;
}
if(isset($cop[$ckey]))
{
$cop = $cop[$ckey];
}
else
{
return;
}
}
if(isset($cop[$pop_ckey]))
{
if(!is_array($cop[$pop_ckey]))
{
setcookie($cookie_key."[".$pop_ckey."]",NULL,-1,$path,$doma);
}
else
{
$cookie_str = http_build_query(array($cookie_key."[".$pop_ckey."]" =&> $cop[$pop_ckey]));
$cookie_arr = explode("",$cookie_str);
foreach($cookie_arr as $cookie)
{
$a_cookie = explode("=",$cookie);
setcookie(urldecode($a_cookie[0]),NULL,-1,$path,$doma);
}
}
unset($cop[$pop_ckey]);
}
}
}
else
{
if(!empty($_COOKIE))
{
$cookie_str = http_build_query($_COOKIE);
$cookie_arr = explode("",$cookie_str);
foreach($cookie_arr as $cookie)
{
$a_cookie = explode("=",$cookie);
setcookie(urldecode($a_cookie[0]),NULL,-1,$path,$doma);
}
$_COOKIE = array();
}
}
}
雖然cookie和session都可以實現題主所想要的功能，但是更推薦使用session。
原因無他，只因為更安全，不容易被截獲偽造登錄信息。
// 登錄成功後記錄登錄信息
$_SESSION["loginStatus"] = array(
"username" =&> $username,
"status" =&> true,
"loginTime" = &> time(),
);
.
.
.
// 判斷session信息
if(empty($_SESSION["loginStatus"]["status"]) || !$_SESSION["loginStatus"]["status"]) {
// 引導到登錄頁
} else {
// 載入用戶信息
}
PS個人感覺「記住我」這個功能是個偽命題，其實只需要在用戶點擊登錄按鈕後直接判斷session信息，就可以直接跳轉到登錄成功後或是登錄前繼續操作的頁面了。完全沒有必要再顯示一個記住我可以點擊登錄的登錄頁，當然這裡涉及到UED方面的知識，但是個人感覺完全沒必要幾個頁面跳來跳去的，直接用AJAX請求數據判斷就可以了。
萌新求贊求關注O(∩_∩)O各位大蝦好，我是只是說我自己的理解....
如果只用cookie的話貌似也可以實現登錄功能，不過一般都是用session來實現登錄吧？
在php中session_start之後就會產生一個session文件，一般放在tmp目錄中，同時會設置一個客戶端的cookie，而這個cookie的值，其實就是隨機產生的session id，這樣一次會話也就建立了
這樣每次發送http請求的時候，伺服器就將cookie中獲得session id和那個session的文件內容關聯起來了，php的程序中也就可以通過超級全局變數$_SESSION來獲得session信息了
不過到目前為止，還只是一次會話的建立，不算是用戶登錄，一般意義上的登錄應該指的是把當前用戶的信息和此次會話關聯起來，在php中一般就是，先通過用戶提交的用戶名和密碼進行驗證，將衍生後的信息給$_SESSION賦值
我覺得這樣就是一次登錄的過程吧，大概整理一下是：
1.session start 建立會話
2.通過用戶發送的用戶名密碼進行驗證，驗證成功則將用戶信息與會話關聯
會話的建立讓伺服器始終知道這些請求是同一個用戶，用戶登錄是讓伺服器知道這一直是哪一個用戶
究其原因還是因為http本身是無狀態協議，所以應用程序本身就要在兩頭保存一些信息進行狀態的確認
各位大蝦，一直以來我就是這麼實現的登錄，自己也不知道有沒有什麼問題，如果有問題的話大俠們一定要指出啊，尤其是安全方面的
這樣省得我以後犯更嚴重的錯誤PHP中有cookie相關的函數， 用戶登錄成功的時候，可能有如下的語句：
setcookie("user", "user1", time()+3600);判斷用戶是否登錄的時候，有類似這樣的語句：
if (isset($_COOKIE["user"])){echo "已經登錄";}
用戶退出的時候，有類似這樣的語句：
setcookie("user", "", time()-3600);如果用戶登錄後一直沒點退出按鈕，3600秒之後，cookie也會失效。如果想讓用戶保持足夠長的時間 time()+3600*24*365 就是登錄後一年內都有效。1. cookies存儲session_id. 一般這個地方會另外再存儲用戶名和其他信息的再次hash值. 用以加強驗證session_id. 因為一個session_id很容易被取到偽造, 當網站session數量比較大還可能被窮舉到.
2. 舉例PHP, session用session_set_save_handler重寫, 以便不會被系統默認session中gc回收(默認1440秒). PHP中系統回收不管任何情況, 只按照session存儲時間來, 超過1440秒並滿足觸發條件就可能回收, 所以session目錄如果公用一個, 沒有單獨設置, 一定會被回收.3. 重寫session_set_save_handler的時候用session_id和session_name判斷接管訪客cookies中是否存在此session_id, 存在進行驗證 1 中的附加欄位判斷是否正確, 正確的話接管, 調出伺服器中存儲的session信息, 開始使用. 不正確回收瀏覽器cookies中session_id, 並重新生成cookies中session_id.大概思路就是上面, 我一般把session存儲在redis中. 不要把這東西存資料庫, 負載太大.
/**************** 我是分割線 ****************/
2016-06-11更新：
對 @小雷 的方法寫了點看法，結果…
以下我詳細對小雷的疑問說明下：以下是你文章中的內容:
-----------------------------1、將用戶信息，比如一個["uid"=&>123, "username"=&>"testuser"]的數組，序列化後成為字元串，使用可逆加密演算法加密該字元串，寫到一個Key為userinfo的COOKIE里2、infodig驗證通過後，使用解密演算法解密userinfo串，得到用戶信息，如果用戶信息里的uid存在用戶表中，則寫SESSION，通過SESSION保持本次會話-----------------------------不知道你這裡的&<&<&<可逆加密演算法加密該字元串&>&>&>&<&<&<使用解密演算法解密userinfo串&>&>&>是我眼花了嗎? 我理解你這樣: 解密cookies中的uid用來進行資料庫查詢判斷用戶是否存在. 不知道我有沒有理解錯你的信息?
我們說說問題:
1. cookies不能存可逆加密的任何信息, 即使你另外加了一個不可逆的hash的cookies欄位, 也保護不了這個可逆的cookies欄位.
2. cookies存儲的僅僅是session_id, 也就是默認那個PHPSESSID, 我一般會修改客戶端cookies存儲名字, 不用PHPSESSID, 用session_name修改為xxx_sessid, xxx為網站識別碼, 比如可以用域名中間部分, 這樣可以在同域名下區分出不同系統.
3. 用戶的uid, username, lifetime, iflogin等信息只能存在session中, 也就是$_SESSION數組中, 不能存在cookies中, 即使是可逆加密, 即使是另外加了一個不可逆的hash欄位.
4. 第2點說到cookies存儲的僅僅是session_id, 意思是我們完全可以cookies只存儲session_id, 其他什麼都不存儲, session_name定義2中的名字後, session_start()開啟會話, 此時session和cookies中session_id已經對接上, 登錄成功. 判斷伺服器$_SESSION中是否存在uid, username, lifetime, iflogin, 判斷登錄, 開始登錄後邏輯.
5. 以上有問題沒? 其實也沒啥問題, 但是session_id就是一段簡單的字元串, 從4中我們可以看出只要客戶端存在這個字元串, 系統的SESSION就接收並判斷伺服器對應存儲的會話是否有登錄. 這段字元串看著總是太單薄, 所以我們習慣性會額外添加點驗證內容:
xxx_sessid ubq4il6v3eiqsbbv9q6uknlpj4xxx_uid 356a192b7913b04c54595428abxxx_uname 385fa818765b90ddc68cd6a以上xxx_sessid即為session_name自定義的PHPSESSID, 自定義PHPSESSID的好處第2點中講了.
xxx_uid和xxx_uname是用戶id和用戶名, 可以用不同於系統密碼hash的另外演算法進行hash.
用session_name定義好session的環境變數, 這樣session_start開啟會話會自動判斷客戶端瀏覽器是否存在xxx_sessid(PHPSESSID), 不存在會自動生成一個xxx_sessid, 進行登錄判斷並進入登錄步驟, 存在即接管.
此時我們有$_SESSION數組可用了, 我們對伺服器的$_SESSION["xxx_uid"], $_SESSION["xxx_uname"] 進行cookies的hash演算法的hash, 跟客戶端$_COOKIES["xxx_uid"], $_COOKIES["xxx_uname"]進行比較, 比對不成功, 回收session和cookies, 因為此會話如果比對不成功說明兩者都不安全, 進入登錄步驟. 比對一致說明此xxx_sessid沒啥問題, 不是窮舉而來的, 驗證通過. 進入登錄後邏輯. 利用$_SESSION["xxx_uid"]查出用戶信息.
6. xxx_uid不存在怎麼辦? 比如此用戶已經被刪掉? 要明白一點: session和cookies管的就是登錄會話. 絕對不要混入用戶管理邏輯中. 當上面步驟驗證登錄成功後, 利用$_SESSION["xxx_uid"]查出用戶信息. 此時發現查詢不到用戶, 即可回收session和cookies會話, 進入登錄步驟. 因為用戶不存在了,說明此用戶會話需要被回收. 如果我們存儲一個$_SESSION["xxx_upass"], 還可以利用登錄後查詢用戶信息的時候比對下用戶密碼, 這樣可以實現修改密碼後所有已經登錄的會話全部要重新登錄. 這些都是在伺服器端$_SESSION信息實現的.
7. 以上只是簡單說明, 具體使用中還包括很多, 比如cookies生效域, 路徑, 時間. session會話前如何用setcookie定義session_name和session_id, session存儲在文件中, redis中等的方法和注意點. 再往大了說涉及到不同域名的單點登錄如何進行. 還有集群中如何部署並平衡, 就不一一說明了.
你的問題在哪裡呢?
1. 你思想上還停留在利用cookies保存用戶信息上面, cookies我們僅僅是保存PHPSESSID, 並額外做一點點驗證.
2. PHP對session_id, session_name, session_start所作的工作要深刻理解並利用上, 不行就看看手冊, 官方手冊有比較明了的說明了. 加以理解並自己設計.
3. 實現一個問題的辦法很多種, 當半懂不懂的時候是很希望別人來指教一二並改進的, 我有些問題半懂不懂的時候多希望別人能來指教一二. 前幾天做PHP擴展的時候有個問題不明白到處求爺爺, 告奶奶. 可人家不鳥你. 人家有人家的忙處, 沒那個義務去幫你. 最後在韓老大的Swoole群里有個熱心的朋友給我指點了一二, 頓悟, 遂完成那個PHP擴展.
三人行必有我師, 只是07年就研究過這玩意, 還算明了一些. 所以探討下. 我也很希望看到更好的建設性方法, 我會虛心學習, 並立刻修改我封裝的session驗證類庫.
歡迎拍磚.
點不點贊無所謂, 點贊我學不到東西, 你學到東西.拍磚我能學到東西.前面說的用user name作為session標識，存用戶數據每次請求從session取數據到資料庫校驗，都是錯誤的做法。
第一個做法完全避免不了構造請求獲取用戶數據，也做不到靈活使用session，沒有登錄的就沒有session數據？第二個做法完全誤用session的作用，如果拿了session存的用戶帳號還要去資料庫取數據，那session存用戶帳號完全無意義。此外退出瀏覽器並不會自動刪除網站cookie數據，非主動清除的情況下cookie的有效期是根據set cookie的超時時間值確定的，超時才會清理。1、sessionid是怎麼生成的，在接收請求之後，就需要判斷cookie是否提交sessionid參數，不存在則生成一個標識通過set cookie通知瀏覽器記錄sessionid。同時以此sessionid為標識存瀏覽器會話狀態所需的數據在伺服器。
這個操作與是否登錄無關。任何請求都可設置這個操作。用於標識瀏覽器與伺服器的會話狀態。2、如何實現記錄用戶登錄狀態，通常會在登錄校驗之後在cookie失效時間上面下功夫，而不是將用戶名密碼用任何形式存儲在客戶端或客戶端。比如在1步的情況下，set cookie通知瀏覽器此cookie失效時間為一個月，同時服務端的緩存記錄登錄狀態，失效時間也設置成一個月。
這樣只要瀏覽器不清理cookie，每一個請求服務端的參數都會自動把cookie裡面存的sessionid提交給服務端，這樣服務端可以通過get_session_info(sessionid)獲取會話狀態的敏感數據，比如登錄狀態，用戶名之類的數據。這樣就實現了登錄狀態的保存。
3、不建議做的事情不建議在瀏覽器前端做任何記錄用戶個人信息的操作，存個標識即可。不建議在取session數據的時候做任何讀取資料庫的操作，使用session的目的就是把瀏覽器會話所需的數據緩存，避免讀取資料庫。不建議使用單個sessionid作為標識，像 左岸 的回答一樣，使用至少一個隨機字元串作為校驗標識，避免sessionid撞庫。cookie和session
看具體需求了，如果是本地記住那就直接用Cookie，把用戶名等信息存起來，這就夠了。如果是一段時間內任何地方免登錄那就用Session存在伺服器。然後當你訪問網站時直接判斷cookie或者session是否存在有效的登錄信息。當然為了安全，你可以通過一些加密手段將用戶信息加密之後再存儲起來。
我記得韓順平老師的視頻裡面，有一塊專門教寫登錄模塊的教程。
你談了一個女朋友，每次都需要敲門，有一天她給你一把鑰匙，說以後你不用敲門，直接用鑰匙開門就行了。
你訪問一個網站，每次都需要登錄，有一天你勾上了「記住我」，之後就不用登錄了，直接用COOKIE中的信息就可以登錄。這兩個例子原理相同。Cookie存儲加密的密碼.訪問的時候伺服器用Cookie里存儲的密碼驗證
推薦閱讀：
※網頁前端和後台人員都是如何看待全棧工程師的？
※如何成為一個優秀的 PHP 工程師？
※待進階的phper 想要通讀一個開源項目源碼，應該研究哪個較好？
※對於PHP程序初學者來說，有沒有比較好的開源項目適合學習和深入的呢？
※相對於別的php框架來說thinkphp有什麼缺點嗎？