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