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概念掌握得不好，見諒：
