Laravel5 快速認證邏輯流程的分析

這篇文章主要介紹了關於Laravel5 快速認證邏輯流程的分析，有著一定的參考價值，現在分享給大家，有需要的朋友可以參考一下

Laravel5本身內建一套使用者認證功能，只需在新項目下，使用命令列php artisan make:auth 和 php artisan migrate就可以使用內建的快速認證功能。

以下為分析登入功能的邏輯分析，以Laravel 5.5版本為準。

通過命令php artisan route:list得到登入路由（紅框）：

開啟查看/app/Http/Controller/Auth/LoginController.php，檔案代碼很簡潔，其實登入邏輯和方法都整合在Illuminate/Foundation/Auth/AuthenticatesUsers的trait裡了：

查看Illuminate\Foundation\Auth\AuthenticatesUsers代碼的login方法，參數$request為請求對象，包含登入請求的資訊包括登入名稱、密碼等：

line31: validateLogin方法負責調用controller本身的validate方法驗證使用者名稱和密碼是否符合簡單規則，這個就沒必要深入講了。

值得注意的是紅框標註的username方法，開發人員可以在LoginController自訂該方法覆蓋trait此方法，自訂登入帳號欄位，trait預設為'email'。

勿直接更改trait的username()方法，保持Laravel5架構的完整性，道理就不詳說了。

line36：hasTooManyLoginAttempts方法，用於檢驗帳號嘗試登入的次數是否達到設定的最大值。

此方法引用於Illuminate\Foundation\Auth\ThrottlesLogins的trait。看trait名稱就猜得出它是負責避免暴力登入用的。

中的limiter()返回RateLimiter對象（顧名思義：頻率限制器），該對象是app服務容器建立的。該對象源於：Illuminate\Cache\RateLimiter檔案。

從該對象的位置可以看出，它使用了Laravel緩衝機制處理登入次數。

所以hasTooManyLoginAttempts方法是調用了RateLimiter對象的tooManyAttempts方法驗證登入次數：

tooManyAttempt方法有三個參數：

$key：用於cacche儲存當前帳號的登入次數值的相對應key。該key組成是這樣的：

所以該key值大致是這樣的："email|101:10:45:12"。從這裡可以看得出該暴力破解防範是利用了ip。當然了要是換IP我還是可以再去嘗試登入的，雖然總有局限性，但總比裸著強多了。

$maxAttempts：最大嘗試登入次數設定值。

該值是可以自訂的，可以寫在LoginController自訂maxAttempts屬性，預設為5次：

$decayMinutes：達到最大嘗試次數後恢複登入的等待時間長度（分鐘數）。

該值也是可自訂的，在LoginController自訂該屬性，預設1分鐘：

回到RateLimiter::tooManyAttempts方法，該方法會判斷當前登入次數是否達到設定值，如果達到設定值並且還在距離上一次禁止登入時間範圍內，則返回true，表示目前使用者(IP）還在禁止登入狀態。

中的紅框，用於判斷緩衝中是否存在$key.':timer'值，該值用了上面的$decayMinutes時間作為到期時間，所以該值的存在與否是恢複登入狀態的關鍵。

如果該緩衝值不在，則目前使用者可以登入了。這時resetAttempts方法清除$key緩衝登入次數值，從零開始記錄。

代碼執行權再次回到Illuminate\Foundation\Auth\AuthenticatesUsers的line36行：

當hasTooManyLoginAttempts返回true時，則發起Lockout事件，並返回LockoutResponse響應。使用者可以產生Lockout事件監控器，用於處理該事件關連的邏輯，比如記錄登入日誌等。

LockoutResponse響應實質上是拋出驗證異常，該異常會自動被Laravel解釋為423狀態代碼的響應，並附帶auth.throttle配置資訊。該配置原始語言位於：/resources/lang/en/auth.php。使用者可以在自訂自己的語言資訊。

接著，回到Illuminate\Foundation\Auth\AuthenticatesUsers的line42行，開始執行登入驗證了：

attemptLogin方法通過config/auth.php配置的看守器名稱，產生對應的看守器對象，然後調用該對象的attempt進行登入驗證。

Laravel5看守器目前支援兩種：SessionGuard和tokenGuard，都儲存於Illuminate\Auth檔案夾中，它們都實現於Illuminate\Contracts\Auth\Guard介面，所以如果需要自訂看守器請實現該介面。
如果要實現web的看守器可進一步實現Illuminate\Contracts\Auth\StatefulGuard介面。

至於在哪種情況下使用哪種看守器，都在config/auth.php中配置：

由於這次我分析的是web登入流程，所以要查看Illuminate\Auth\sessionGuard的attempt方法：

line 351： 這行作用是通過配置的提供器provider來檢索該帳號資訊。提供器也有兩種：DatabaseUserProvider和EloquentUserProvider。檔案位於：/Illuminate/Auth。

具體使用哪種通過config/auth.php的providers參數配置，配置好後還要在'guards‘參數中指定使用哪種提供器。提供器實質上就是提供哪種方式查詢資料庫帳號表，database就是直接用資料庫Db門面查詢，eloquent則用模型查詢。

Laravel預設用的是EloquentUserProvider，查看該retrieveByCredentials方法，很明顯看得出是直接帳號名來查詢該使用者資訊：

回到Illuminate\Auth\sessionGuard的attempt方法，line356行的hasValidCredentials方法則進行驗證密碼，如果上一步的使用者資訊能正常檢索的話。

從hasValidCredentials方法體可以看出，它調用了提供器的validateCredentials方法來進行密碼驗證。查看下EloquentUserProvider::validateCredentials方法：

該驗證方法使用了HasherContract契約實現的雜湊類的check方法。具體的實作類別有：Illuminate\Hashing\BcryptHasher。我們查看該類的check方法：

很明顯，它使用了password_verify函數將輸入的純文字密碼來比對已散列的密碼值。這要求了資料庫的密碼都已經用了password_hash進行散列處理。

如果驗證密碼成功，則返回true。回到sessionGuard執行line357的login方法，記錄session和cookie登入狀態。

儲存的session的key和value分別為：

‘key'=>'login_session_'.sha1(static::class) //static::class指代sessionGuard類本身

‘value'=>目前使用者的主索引值

如果使用了remember_me選項，則儲存以下cookie，key和value如下：

‘key'=>''remember_session_'.sha1(static::class) //static::class指代sessionGuard類本身

'value'=>使用者主索引值.'|'.儲存的最近一次remember_token值.'|'.使用者密碼散列值

到此，使用者已成功登入，執行點又最後回到Illuminate\Foundation\Auth\AuthenticatesUsers的line42，attemptLogin已執行完畢並返回true，然後調用sendLoginResponse方法跳轉到登入後首頁面或上一次登入的頁面。

注意authenticated方法是空方法，可以在LoginController重定義該方法自訂登入後如何跳轉和處理其他邏輯。

如果未成功登入，則執行Illuminate\Foundation\Auth\AuthenticatesUsers的incrementLoginAttempts($request)方法，增加一次失敗登入次數。增加次數的方法同樣是間接調用RateLimiter類的hit()方法。
最後調用sendFailedLoginResponse返回登入異常。

最後附上時序圖，畫得一般般，有些UML概念掌握得不好，見諒：

以上就是本文的全部內容，希望對大家的學習有所協助，更多相關內容請關注topic.alibabacloud.com！