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