1. 什么是Guard
在Laravel/Lumen
框架中,用户的登录/注册的认证基本都已经封装好了,开箱即用。而登录/注册认证的核心就是:
- 用户的注册信息存入数据库(登记)
- 从数据库中读取数据和用户输入的对比(认证)
上述两步是登录/注册的基本,可以看到都会涉及到数据库的操作,这两步框架底层已经帮我们做好了,而且考虑到了很多情况,比如用户认证的数据表不是user表
而是admin_user
,认证字段是phone
而不是email
,等等一些问题都是Guard
所要解决的,通过Guard
可以指定使用哪个数据表什么字段等,Guard
能非常灵活的构建一套自己的认证体系。
通俗地讲,就是这样:Guard
就像是小区的门卫大叔,冷酷无情,不认人只认登记信息。进小区之前大叔需要先检查你的身份,验证不通过大叔就不让你进去。如果是走路/骑车进去,大叔1需要检查你的门禁卡,他拿出记录了小区所有业主门禁卡信息的本子查看你这个门禁卡信息有没有在这个本子上;如果你开车进去,大叔2就从记录了所有业主车牌号的本子中检查你的车牌号,所以新业主要小区了需要告知门卫大叔们你的门禁卡信息或者车牌号,要不然大叔2不让你进。如果是物业管理员要进小区,门卫大叔3也只认登记信息,管理员出示他的管理员门禁卡,门卫大叔就会检查记录了管理员门禁卡信息的本子。
上面讲的对应了框架中的多用户认证:
- 走路/骑车的人 -> 门禁卡
- 开车的人 -> 车牌号
- 物业管理员 -> 门禁卡
门禁卡和车牌号都是不同的认证方式,而门卫大叔查看的本子就对应了不同数据库中的用户信息,这样讲是不是更容易理解了。
Lumen/Laravel
中以中间件(Middleware
)的方式提供了非常灵活的认证,通过简单的配置就可以切换多个认证。
注:本文所讲的都是
Lumen
的代码,是Laravel
精简版,内部实现原理都大差不差本文所使用的是:Laravel 7.29
2. Guard工作流程
说了这么多,附上一张手工制作的流程图:
946
从图中可以看到,一个Guard
会涉及到三个部分,分别是:
Guard
实现本身User Provider
用户提供者,指定哪个数据表以什么方式获取(eloquent/database
)Authenticatable
接口规定那些东西可以被认证,就是实现它的接口嘛
2. 从配置说起
深入底层代码之前,先从配置文件讲起。认证的配置主要在/config/auth.php
中,里面可以定义各种认证的门卫大叔(guard):
1 | // /config/auth.php |
配置中定义了两个门卫user
和admin
,driver
字段设置门卫的认证系统,默认提供两种sessesion
和token
,provider
定义的就是上面说的本子,保存所有的认证用户,provider
下面的drive
定义认证用户如何获取,有两种方式database
和eloquent
方式,一般都是用第二种,model
定义eloquent
方式使用的数据模型,如果driver
是database
,就要设置table
指定数据库表。如果没有代码中没有指定用哪个门卫,就会使用默认的门卫大爷:
1 | 'defaults' => [ |
3. 使用Guard例子
我们以Laravel
中auth
中间件例子来简单说一下:
1 | Route::get('/user/profile', 'UserController@profile')->middleware('auth'); |
4. 分析
当发起/user/profile
这个请求时,在进入UserController::profile
方法前,会调用auth
中间件,auth
定义在\app\Http\Kernel.php
中:
1 | // \app\Http\Kernel.php |
对应处理脚本是\App\Http\Middleware\Authenticate::class
,
1 | // \app\Http\Middleware\Authenticate.php |
Laravel
中中间件的处理入口都是handle
方法,参数中会一数组形式传过来多个使用的guard
,比如这样:
1 | Route::get('/user/profile', 'UserController@profile')->middleware('auth:session,foo,bar'); |
middleware()
中冒号前后分别是中间件和参数。
handle
方法很简单嘛,就是调用了authenticate()
:
1 | // \Illuminate\Auth\Middleware\Authenticate.php |
authenticate()
方法遍历传过来的guard
,然后check()
,只要满足其中一个,就直接返回,否则就会抛出AuthenticationException
异常。
⚠️注意
1 | $this->auth->guard($guard)->check() |
这个是关键,它是通过在auth
属性上链式调用的,我们来一步一步分析下:
1 | // \Illuminate\Auth\Middleware\Authenticate.php |
这里的$auth
其实是\Illuminate\Contracts\Auth\Factory
接口的一个实例,通过构造函数注入进来,通过dd($this->auth)
方式发现这个其实就是Illuminate\Auth\AuthManager
实例,它实现了Illuminate\Contracts\Auth\Factory
接口:
1 | // \Illuminate\Contracts\Auth\Factory.php |
这个接口有guard()
方法,所以上面可以直接链式调用。
通过接口定义的声明,我们可以知道guard()
返回\Illuminate\Contracts\Auth\Guard
或者\Illuminate\Contracts\Auth\StatefulGuard
这两个接口,具体在AuthManager
中的实现是这样的:
1 | // \Illuminate\Auth\AuthManager.php |
通过我们在middleware()
中传过来的参数创建对应的guard
实例,没有就是默认driver
对应的guard
,最后check()
。
这节最后讲一下
AuthManager
是什么时候创建的?
Laravel
框架初始化时,很多服务都是以服务提供者(ServiceProvider
)的形式创建的,AuthManager
就是AuthServiceProvider
创建的:
1 | // \Illuminate\Auth\AuthServiceProvider.php |
AuthServiceProvider
中在注册时调用registerAuthenticator()
,创建auth
单例指向AuthManager
实例。
通过上面的一波分析,我们知道guard
的创建是受AuthManager
管理的,AuthManager
在这里的指责就是解析driver
并创建guard
。
所以现在整个middleware('auth')
的流程大致如下:
30992
5. Guard接口
上面说到AuthManager
创建了guard
,然后调用check()
,我先现在来分析下Guard
。还是那句话,不管上层业务代码多么复杂,底层的接口往往是很简单的。Lumen/Laravel
框架中大部分接口被设计成是一种契约(Contracts)
,Guard
也一样的,它的代码在\vendor\illuminate\contracts\Auth\Guard.php
文件中,只有6个方法:
1 | // \Illuminate\Contracts\Auth\Guard.php |
很简单,有木有~同样,还有一个StatefulGuard
接口,继承自Guard
接口并加了几个有状态的方法,代表有状态,就是每次请求都带有用户的状态信息比如session
,代码如下:
1 | // Illuminate\Contracts\Auth\StatefulGuard.php |
UML
图大致如下:
38545
6. Guard接口的相关实现
底层接口着实简单,再来分析下上层的实现代码,框架中默认实现了几个Guard
,比如Web开发用到的SessionGuard
,接口开发用到的TokenGuard
,这些都实现自\Illuminate\Contracts\Auth
或者\Illuminate\Contracts\Auth\StatefulGuard
,已经满足我们日常所需了。
几个Guard
的check()
方法都是一样的,都定义在GuardHelpers
这个Trait
中:
1 | // \Illuminate\Auth\GuardHelpers.php |
user()
就是在不同的Guard
中实现了,后面也主要看这个方法。
40457
什么是Trait:
你可以理解成一系列方法的集合,就是把经常使用到的重复方法整合起来,在class里面直接use使用,上下文还是引用它的那个class,减少了重复代码量,而且比class更轻量,不需要new在使用。
6.1 RequestGuard.php
RequestGuard
认证一个http
请求,具体怎么认证,它是通过callback
实现的,认证逻辑在callback
中直接放到了上层让用户自定义,UML
图:
40762
看代码实现也很简单:
1 | // \Illuminate\Auth\RequestGuard.php |
RequestGuard
很多文章都是一笔带过,这里我说一下,通常我们使用不到RequestGuard
,只有在自定义Guard
时才用得上。
使用方式如下
AuthServiceProvider
中注册自定义的guard
,设置名称和callback
:
1 | // App\Providers\AuthServiceProvider.php |
auth.php
中配置自定义guard
1 | 'guards' => [ |
- 使用
还是上面的例子:
1 | Route::get('/user/profile', 'UserController@profile')->middleware('auth:my-api'); |
最后在认证的时候就会直接使用我们设置的callback
了。
上面viaRequest()
也是定义AuthManager
中:
1 | // \Illuminate\Auth\AuthManager.php |
6.2 SessionGuard
见名知义,此guard
是基于session
的,一般最常用的就是这个了。由于是基于session
所以是有状态的,所以这个类定义的时候实现了StatefulGuard
接口,而且加了更多逻辑代码和注释加起来有800+行,
1 | // \Illuminate\Auth\SessionGuard.php |
UML
图:
53162
用户认证的代码稍微复杂一点,如下:
1 | // \Illuminate\Auth\SessionGuard.php |
梳理下,大致是先从session
获取用户的主键id
,然后通过特定的UserProvider
查找用户,查找成功说明验证成功,如果没有,就用recaller
查询用户,这里就是remember token
查找,就是登录时“记住我”的那个选项,remember token
是保存在cookie
当中的,如果remember token
查找成功,就说明验证成功,否则验证失败。
6.3 TokenGuard
TokenGuard
也实现了Guard
接口,适用于无状态的api
认证,UML
图:
60309
由于不要维护状态整个代码就简单很多:
1 | // \Illuminate\Auth\TokenGuard.php |
先从请求中获取api_token
,再用api_token
从指定的UserProvider
查找api_token
对应的用户信息。
至此,Laravel
中Guard
相关的分析已经差不多了,通过分析它的源码,我们深入了解了框架背后的思想,梳理的过程也是学习的过程,对新手而言能快速掌握guard
的相关知识并快速上手,对老鸟而言,我觉得这篇文章写的已经很细了,能更好地了解框架背后的精髓写出更优雅的代码。
总结
在深入学习Guard
源码后,了解到底层归纳为两个核心,一是UserProvider
,认证用户数据来源,通常是本地数据库,二是认证逻辑,逻辑这块主要就是Guard
来做了。对于自定义Guard
,上面也稍微讲了一点,通过AuthManager
的viaRequest
来做,对于用户数据源我们也不必拘泥于现有的,我们也可以将数据源指向redis
或者远程接口,只要实现相关接口,比如这样:
1 | namespace app\Providers; |
也可以从远程接口获取:
1 | class ApiUserProvider implements UserProvider |
最后,附上一张我在学习过程中总结的UML
图:
71549
欢迎阅读本篇文章,如有兴趣可以关注博主公众号哦: