普通地讲,便是这样:Guard就像是小区的门卫大叔,冷漠无情,不认人只认登记信息。进小区之前大叔须要先检讨你的身份,验证不通过大叔就不让你进去。如果是走路/骑车进去,大叔1须要检讨你的门禁卡,他拿出记录了小区所有业主门禁卡信息的本子查看你这个门禁卡信息有没有在这个本子上;如果你开车进去,大叔2就从记录了所有业主车牌号的本子中检讨你的车牌号,以是新业紧张小区了须要奉告门卫大叔们你的门禁卡信息或者车牌号,要不然大叔2不让你进。如果是物业管理员要进小区,门卫大叔3也只认登记信息,管理员出示他的管理员门禁卡,门卫大叔就会检讨记录了管理员门禁卡信息的本子。
上面讲的对应了框架中的多用户认证:
门禁卡和车牌号都是不同的认证办法,而门卫大叔查看的本子就对应了不同数据库中的用户信息,这样讲是不是更随意马虎理解了。

Lumen/Laravel中以中间件(Middleware)的办法供应了非常灵巧的认证,通过大略的配置就可以切换多个认证。
注:本文所讲的都是Lumen的代码,是Laravel精简版,内部实现事理都大差不差
本文所利用的是:Laravel 7.29
2. Guard事情流程说了这么多,附上一张手工制作的流程图:
从图中可以看到,一个Guard会涉及到三个部分,分别是:
Guard实现本身User Provider用户供应者,指定哪个数据表以什么办法获取(eloquent/database)Authenticatable接口规定那些东西可以被认证,便是实现它的接口嘛2. 从配置提及深入底层代码之前,先从配置文件讲起。认证的配置紧张在/config/auth.php中,里面可以定义各种认证的门卫大叔(guard):
// /config/auth.php'guards' => [ 'user' => [ 'driver' => 'session', 'provider' => 'users', ], 'admin' => [ 'driver' => 'token', 'provider' => 'admin_users', ],],'providers' => [ 'users' => [ 'driver' => 'eloquent', 'model' => App\Models\User::class,// 'table' => 'user' ], 'admin_users' => [ 'driver' => 'eloquent', 'model' => App\Models\AdminUser::class, ],],
配置中定义了两个门卫user和admin,driver字段设置门卫的认证系统,默认供应两种sessesion和token,provider定义的便是上面说的本子,保存所有的认证用户,provider下面的drive定义认证用户如何获取,有两种办法database和eloquent办法,一样平常都是用第二种,model定义eloquent办法利用的数据模型,如果driver是database,就要设置table指天命据库表。如果没有代码中没有指定用哪个门卫,就会利用默认的门卫大爷:
'defaults' => [ 'guard' => 'users', 'passwords' => 'users',],
3. 利用Guard例子
我们以Laravel中auth中间件例子来大略说一下:
Route::get('/user/profile', 'UserController@profile')->middleware('auth');
4. 剖析
当发起/user/profile这个要求时,在进入UserController::profile方法前,会调用auth中间件,auth定义在\app\Http\Kernel.php中:
// \app\Http\Kernel.phpprotected $routeMiddleware = [ 'auth' => \App\Http\Middleware\Authenticate::class, 'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class, 'bindings' => \Illuminate\Routing\Middleware\SubstituteBindings::class, 'cache.headers' => \Illuminate\Http\Middleware\SetCacheHeaders::class, ...];
对应处理脚本是\App\Http\Middleware\Authenticate::class,
// \app\Http\Middleware\Authenticate.php/ Handle an incoming request. @param \Illuminate\Http\Request $request @param \Closure $next @param string[] ...$guards @return mixed @throws \Illuminate\Auth\AuthenticationException/public function handle($request, Closure $next, ...$guards){ $this->authenticate($request, $guards); return $next($request);}
Laravel中中间件的处理入口都是handle方法,参数中会一数组形式传过来多个利用的guard,比如这样:
Route::get('/user/profile', 'UserController@profile')->middleware('auth:session,foo,bar');
middleware()中冒号前后分别是中间件和参数。
handle方法很大略嘛,便是调用了authenticate():
// \Illuminate\Auth\Middleware\Authenticate.php/ Determine if the user is logged in to any of the given guards. @param \Illuminate\Http\Request $request @param array $guards @return void @throws \Illuminate\Auth\AuthenticationException/protected function authenticate($request, array $guards){ if (empty($guards)) { $guards = [null]; } foreach ($guards as $guard) { if ($this->auth->guard($guard)->check()) { return $this->auth->shouldUse($guard); } } $this->unauthenticated($request, $guards);}
authenticate()方法遍历传过来的guard,然后check(),只要知足个中一个,就直接返回,否则就会抛出AuthenticationException非常。
⚠️把稳$this->auth->guard($guard)->check()
这个是关键,它是通过在auth属性上链式调用的,我们来「公众年夜众号」(正义的程序猿)一步一步剖析下:
// \Illuminate\Auth\Middleware\Authenticate.phpnamespace Illuminate\Auth\Middleware;use Closure;use Illuminate\Auth\AuthenticationException;use Illuminate\Contracts\Auth\Factory as Auth;use Illuminate\Contracts\Auth\Middleware\AuthenticatesRequests;class Authenticate implements AuthenticatesRequests{ / The authentication factory instance. @var \Illuminate\Contracts\Auth\Factory / protected $auth; / Create a new middleware instance. @param \Illuminate\Contracts\Auth\Factory $auth @return void / public function __construct(Auth $auth) { $this->auth = $auth; } ...}
这里的$auth实在是\Illuminate\Contracts\Auth\Factory接口的一个实例,通过布局函数注入进来,通过dd($this->auth)办法创造这个实在便是Illuminate\Auth\AuthManager实例,它实现了Illuminate\Contracts\Auth\Factory接口:
// \Illuminate\Contracts\Auth\Factory.phpnamespace Illuminate\Contracts\Auth;interface Factory{ / Get a guard instance by name. @param string|null $name @return \Illuminate\Contracts\Auth\Guard|\Illuminate\Contracts\Auth\StatefulGuard / public function guard($name = null); / Set the default guard the factory should serve. @param string $name @return void / public function shouldUse($name);}
这个接口有guard()方法,以是上面可以直接链式调用。
通过接口定义的声明,我们可以知道guard()返回\Illuminate\Contracts\Auth\Guard或者\Illuminate\Contracts\Auth\StatefulGuard这两个接口,详细在AuthManager中的实现是这样的:
// \Illuminate\Auth\AuthManager.php/ Attempt to get the guard from the local cache. @param string|null $name @return \Illuminate\Contracts\Auth\Guard|\Illuminate\Contracts\Auth\StatefulGuard/public function guard($name = null){ $name = $name ?: $this->getDefaultDriver(); return $this->guards[$name] ?? $this->guards[$name] = $this->resolve($name);}
通过我们在middleware()中传过来的参数创建对应的guard实例,没有便是默认driver对应的guard,末了check()。
这节末了讲一下
AuthManager是什么时候创建的?Laravel框架初始化时,很多做事都因此做事供应者(ServiceProvider)的形式创建的,AuthManager便是AuthServiceProvider创建的:
// \Illuminate\Auth\AuthServiceProvider.phpnamespace Illuminate\Auth;class AuthServiceProvider extends ServiceProvider{ / Register the service provider. @return void / public function register() { $this->registerAuthenticator(); .... } / Register the authenticator services. @return void / protected function registerAuthenticator() { $this->app->singleton('auth', function ($app) { // Once the authentication service has actually been requested by the developer // we will set a variable in the application indicating such. This helps us // know that we need to set any queued cookies in the after event later. $app['auth.loaded'] = true; return new AuthManager($app); }); .... } ....}
AuthServiceProvider中在注册时调用registerAuthenticator(),创建auth单例指向AuthManager实例。
通过上面的一波剖析,我们知道guard的创建是受AuthManager管理的,AuthManager在这里的责怪便是解析driver并创建guard。
以是现在全体middleware('auth')的流程大致如下:
5. Guard接口
上面说到AuthManager创建了guard,然后调用check(),我先现在来剖析下Guard。还是那句话,不管上层业务代码多么繁芜,底层的接口每每是很大略的。Lumen/Laravel框架中大部分接口被设计成是一种左券(Contracts),Guard也一样的,它的代码在\vendor\illuminate\contracts\Auth\Guard.php文件中,只有6个方法:
// \Illuminate\Contracts\Auth\Guard.phpnamespace Illuminate\Contracts\Auth;interface Guard{ // 判断当前用户是否登录 public function check(); // 判断当前用户是否是游客(未登录) public function guest(); // 获取当前认证的用户 public function user(); // 获取当前认证用户的 id,严格来说不一定是 id,该当是这个模型中的主键字段 public function id(); // 用户验证 public function validate(array $credentials = []); // 设置当前认证过的用户 public function setUser(Authenticatable $user);}
很大略,有木有~同样,还有一个StatefulGuard接口,继续自Guard接口并加了几个有状态的方法,代表有状态,便是每次要求都带有用户的状态信息比如session,代码如下:
// Illuminate\Contracts\Auth\StatefulGuard.phpnamespace Illuminate\Contracts\Auth;interface StatefulGuard extends Guard{ // 指天命据验证 public function attempt(array $credentials = [], $remember = false); // 将这一次request验证通过登录,不会保存session/cookie public function once(array $credentials = []); // 登录 public function login(Authenticatable $user, $remember = false); // 利用id登录 public function loginUsingId($id, $remember = false); // 和once()一样,不过是用id public function onceUsingId($id); // 通过remember cookie登录 public function viaRemember(); // 注销 public function logout();}
UML图大致如下:
6. Guard接口的干系实现
底层接话柄在大略,再来剖析下上层的实当代码,框架中默认实现了几个Guard,比如Web开拓用到的SessionGuard,接口开拓用到的TokenGuard,这些都实现自\Illuminate\Contracts\Auth或者\Illuminate\Contracts\Auth\StatefulGuard,已经知足我们日常所需了。
几个Guard的check()方法都是一样的,都定义在GuardHelpers这个Trait中:
// \Illuminate\Auth\GuardHelpers.php/ Determine if the current user is authenticated. @return bool/public function check(){ return ! is_null($this->user());}
user()便是在不同的Guard中实现了,后面也紧张看这个方法。
什么是Trait:
你可以理解成一系列方法的凑集,便是把常常利用到的重复方法整合起来,在class里面直接use利用,高下文还是引用它的那个class,减少了重复代码量,而且比class更轻量,不须要new在利用。
6.1 RequestGuard.phpRequestGuard认证一个http要求,详细怎么认证,它是通过callback实现的,认证逻辑在callback中直接放到了上层让用户自定义,UML图:
看代码实现也很大略:
// \Illuminate\Auth\RequestGuard.php/ Get the currently authenticated user. @return \Illuminate\Contracts\Auth\Authenticatable|null/public function user(){ // If we've already retrieved the user for the current request we can just // return it back immediately. We do not want to fetch the user data on // every call to this method because that would be tremendously slow. if (! is_null($this->user)) { return $this->user; } return $this->user = call_user_func( $this->callback, $this->request, $this->getProvider() );}
RequestGuard很多文章都是一笔带过,这【"大众年夜众号)里我说(正义的程序猿)一下,常日我们利用不到RequestGuard,只有在自定义Guard时才用得上。
利用办法如下AuthServiceProvider中注册自定义的guard,设置名称和callback:// App\Providers\AuthServiceProvider.phpuse App\User;use Illuminate\Http\Request;use Illuminate\Support\Facades\Auth;/ Register any application authentication / authorization services. @return void /public function boot(){ $this->registerPolicies(); Auth::viaRequest('custom-token', function ($request) { return User::where('my-token', $request->my_token)->first(); });}
auth.php中配置自定义guard
'guards' => [ 'my-api' => [ 'driver' => 'custom-token', ],],
利用
还是上面的例子:
Route::get('/user/profile', 'UserController@profile')->middleware('auth:my-api');
末了在认证的时候就会直策应用我们设置的callback了。
上面viaRequest()也是定义AuthManager中:
// \Illuminate\Auth\AuthManager.php/ Register a new callback based request guard. @param string $driver @param callable $callback @return $this/public function viaRequest($driver, callable $callback){ return $this->extend($driver, function () use ($callback) { $guard = new RequestGuard($callback, $this->app['request'], $this->createUserProvider()); $this->app->refresh('request', $guard, 'setRequest'); return $guard; });}
6.2 SessionGuard
见名知义,此guard是基于session的,一样平常最常用的便是(公众年夜众号:)这(正义的程序猿)个了。由于是基于session所以是有状态的,以是这个类定义的时候实现了StatefulGuard接口,而且加了更多逻辑代码和注释加起来有800+行,
// \Illuminate\Auth\SessionGuard.phpnamespace Illuminate\Auth;use Illuminate\Contracts\Auth\StatefulGuard;use Illuminate\Contracts\Auth\SupportsBasicAuth;class SessionGuard implements StatefulGuard, SupportsBasicAuth{ ...}
UML图:
用户认证的代码轻微繁芜一点,如下:
// \Illuminate\Auth\SessionGuard.php/ Get the currently authenticated user. @return \Illuminate\Contracts\Auth\Authenticatable|null/public function user(){ if ($this->loggedOut) { return; } // If we've already retrieved the user for the current request we can just // return it back immediately. We do not want to fetch the user data on // every call to this method because that would be tremendously slow. if (! is_null($this->user)) { return $this->user; } $id = $this->session->get($this->getName()); // First we will try to load the user using the identifier in the session if // one exists. Otherwise we will check for a "remember me" cookie in this // request, and if one exists, attempt to retrieve the user using that. if (! is_null($id) && $this->user = $this->provider->retrieveById($id)) { $this->fireAuthenticatedEvent($this->user); } // If the user is null, but we decrypt a "recaller" cookie we can attempt to // pull the user data on that cookie which serves as a remember cookie on // the application. Once we have a user we can return it to the caller. if (is_null($this->user) && ! is_null($recaller = $this->recaller())) { $this->user = $this->userFromRecaller($recaller); if ($this->user) { $this->updateSession($this->user->getAuthIdentifier()); $this->fireLoginEvent($this->user, true); } } return $this->user;}
梳理下,大致是先从session获取用户的主键id,然后通过特定的UserProvider查找用户,查找成功解释验证成功,如果没有,就用recaller查询用户,这里便是remember token查找,便是登录时“记住我”的那个选项,remember token是保存在cookie当中的,如果remember token查找成功,就解释验证成功,否则验证失落败。
6.3 TokenGuardTokenGuard也实现了Guard接口,适用于无状态的api认证,UML图:
由于不要掩护状态全体代码就大略很多:
// \Illuminate\Auth\TokenGuard.phpnamespace Illuminate\Auth;use Illuminate\Contracts\Auth\Guard;use Illuminate\Contracts\Auth\UserProvider;use Illuminate\Http\Request;class TokenGuard implements Guard{ ... / Get the currently authenticated user. @return \Illuminate\Contracts\Auth\Authenticatable|null / public function user() { // If we've already retrieved the user for the current request we can just // return it back immediately. We do not want to fetch the user data on // every call to this method because that would be tremendously slow. if (! is_null($this->user)) { return $this->user; } $user = null; $token = $this->getTokenForRequest(); if (! empty($token)) { $user = $this->provider->retrieveByCredentials([ $this->storageKey => $this->hash ? hash('sha256', $token) : $token, ]); } return $this->user = $user; } ...}
先从要求中获取api_token,再用api_token从指定的UserProvider查找api_token对应的用户信息。
至此,Laravel中Guard干系的剖析已经差不多了,通过剖析它的源码,我们深入理解了框架背后的思想,梳理的过程也是学习的过程,对新手而言能快速节制guard的干系知识并快速上手,对老鸟而言,我以为这篇文章写得已经很细了,能更好地理解框架背后的精髓写出更优雅的代码。
总结在深入学习Guard源码后,理解到底层归纳为两个核心,一是UserProvider,认证用户数据来源,常日是本地数据库,二是认证逻辑,逻辑这块紧张便是Guard来做了。对付自定义Guard,上面也轻微讲了一点,通过AuthManager的viaRequest来做,对付用户数据源我们也不必拘泥于现有的,我们也可以将数据源指向redis或者远程接口,只要实现干系接口,比如这样:
namespace app\Providers;use Illuminate\Contracts\Auth\Authenticatable;use Illuminate\Contracts\Auth\UserProvider;class RedisUserProvider implements UserProvider{ / Retrieve a user by their unique identifier. @param mixed $identifier @return \Illuminate\Contracts\Auth\Authenticatable|null / public function retrieveById($identifier) { // TODO: 通过id取redis中对应的用户 } ....}
也可以从远程接口获取:
class ApiUserProvider implements UserProvider{ / Retrieve a user by their unique identifier. @param mixed $identifier @return \Illuminate\Contracts\Auth\Authenticatable|null / public function retrieveById($identifier) { // TODO: 通过id布局curl要求结果 }}
末了,附上一张我在学习过程中总结的UML图:
文章首发在我自己的博客:https://xydida.com/2021/2/24/PHP/Laravel/The-Guard-in-Laravel-framework/
欢迎大佬们赏光,文章如果有误,还请大家示正。