用戶庫（users table）內依然有使用者資料存在。 真讓人奇怪。 所以情況是我們丟失了所有內容， 但是至少測試使用者的資訊依然存在。 我們給出的解釋是這是一個測試行為， 所以這些事情有可能發生。
接下來的幾分鐘一片混亂。 我不記得自己做了什麼。 我不認為自己笨到在控制台上執行了刪除用戶庫的操作。 但是事實就是這麼發生了， 現在後臺既沒有了內容庫， 也沒有了用戶庫。
不過， 我還是沒有接受這件事。 我們一開始是如何失去這些東西的？
我開始不停地往深處想。 半是為了否認這件事， 半是想要挽回面子。 不久， 我注意到了一些重要事情。
在伺服器上還存在著其他5個資料庫。 其中一個資料庫的名字和我剛才看到的資料庫名字很像。
當我查看這個資料庫的時候， 發現所有的內容都在裡面。 用戶庫也安然無恙。 結果證明， 是一個配置變動無意中改變了生產設置， 使網站指向了一個全新的資料庫。 我之前所看的使用者資訊是什麼？種子資料。
用戶在登陸之後會從cookie中載入內容， 但是這個頁面卻試圖在沒有任何等待的情況下進行載入。 根據事件的發生順序， 使用者會得到帶來伺服器的反映， 說其是未經授權的。
身份驗證也未檢查權杖是否過期。 如果用戶不經常訪問這個網站。 那麼當其再一次訪問時，
權杖應該基於每個請求進行更新， 但是我從未花費時間去理解其發生前後的規則。 所以， 這又產生了一個時間問題。 如果我們同時發送了幾個請求， 根據它們返回的順序， 使用者會得到那個在後來的請求中無法使用的權杖。
我們匆匆忙忙地趕著項目， 卻仍花費了比規定多一倍的時間。 區別之處在於有更多的漏洞， 並需要花更多時間去跟蹤並修復這些漏洞。
這使我感到窘迫。 之後因為整件事情變得比較糟糕哦而讓我在公眾場合感到羞愧。
我想說的是：在此之後， 我花費了時間去學習認證程式。 我現在瞭解了OAuth、JWT、刷新權杖和到期行為。 我仔細研究了其他人所編寫的身份驗證代碼。 我能夠在不同的語言和框架中建構身份驗證程式。
我能夠在不同的語言和框架中建構身份驗證程式。