本文Laravel版本为5.5
laravel中的实现方式
laravel自带了完整的auth方案，可以参照文章laravel的应用。我这里实现举出几个重要的步骤:
//生成代码
php artisan make:auth
//导入数据表结构
php artisan migrate
重要的文件：
//用户模型
app/Http/User.php
//业务逻辑
app/Http/Controllers/Auth/*.php
//配置文件
config/auth.php
我们观察一下配置文件，个人的理解我加上注释写在后面：
<?php
return [
'defaults' => [ /*默认配置*/
'guard' => 'web', /*guard（我个人看成检验器，翻译是守卫、监视者） 使用web的配置 */
'passwords' => 'users', /*密码管理，使用users的配置*/
],
'guards' => [
'web' => [ /*web的检验器的配置，有驱动器和提供者2个属性*/
'driver' => 'session',
'provider' => 'users',
],
'api' => [ /*api的检验器的配置，有驱动器和提供者2个属性*/
'driver' => 'token',
'provider' => 'users',
],
],
'providers' => [ /*提供者的驱动器和模型*/
'users' => [
'driver' => 'eloquent',
'model' => App\Http\User::class,
]
],
'passwords' => [
'users' => [ /*密码管理的提供者属性*/
'provider' => 'users',
'table' => 'password_resets',
'expire' => 60,
],
]
];
从配置来看，我们可以把laravel的auth看成多个部分(而passwords应该属于其中一项功能):
- 入口(web|api|......)
- 验证器guards
- 提供者providers
分析源码
以登录为例，我们开始进入源码阅读，当我们点进去看LoginController.php时，发现他没有几行代码。但是他用了一个trait，至于什么是trait，请参照php的trait。里面也只是些简单的业务逻辑实现方法，如果不需要，可以重写，或者注释。
但是，我从构造函数发现了，他使用了middleware，如果你不懂什么叫middleware，请参照我个人的bloglaravel(5.5)自定义middle ware。
$this->middleware('guest')->except('logout');
很明显，他使用了中间件进行处理，我们进行代码追踪，就可以进入下一步了。
laravel是如何注入guard
guest这个中间件，定义在app/Http/Kernel.php中。
'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class
主要的代码如下：
public function handle($request, Closure $next, $guard = null)
{
if (Auth::guard($guard)->check()) {
return redirect('/');
}
return $next($request);
}
那，我们找到了我们要找的Auth。Auth是一个门面，也就是一个快捷使用的类的入口，我们找到他的实现类的位置\Illuminate\Auth\AuthServiceProvider，终于算是找到我们的正主了。
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);
});
$this->app->singleton('auth.driver', function ($app) {
return $app['auth']->guard();
});
}
每当请求进入的时候，只要使用了Auth这个门面的地方，都会注册这个验证身份。实现类，就是AuthManager类。在这个类中，有这么一个方法，将验证器注入。
public function guard($name = null)
{
$name = $name ?: $this->getDefaultDriver();
return $this->guards[$name] ?? $this->guards[$name] = $this->resolve($name);
}
发现了嘛？driver就是从这里写入的，配合配置文件中的driver就会生成一个driver类。不过这个代码质量也不是很高，比如下面的：
$driverMethod = 'create'.ucfirst($config['driver']).'Driver';
emmm，硬生生的字符串拼接获取方法名？？？好把，这里按照laravel这么“优雅的框架”，不应该加上工厂模式嘛？额，小小吐槽一次。
laravel的验证器是如何工作的
接下来，我们就可以看他的验证器是如何实现的了。以TokenGuard为例把。
public function createTokenDriver($name, $config)
{
$guard = new TokenGuard(
$this->createUserProvider($config['provider'] ?? null),
$this->app['request']
);
$this->app->refresh('request', $guard, 'setRequest');
return $guard;
}
返回了一个TokeGuard的类，细看下去，里面无非是判断有没有值提交[api_key|api_token]，没有的话就去找http的验证头Authorization Bearer或者$_SERVER['PHP_AUTH_PW']，然后，重要的地方来了。
public function validate(array $credentials = [])
{
if (empty($credentials[$this->inputKey])) {
return false;
}
$credentials = [$this->storageKey => $credentials[$this->inputKey]];
if ($this->provider->retrieveByCredentials($credentials)) {
return true;
}
return false;
}
这里直接查表？条件就是key= input key的模式，实在太恐怖了，查表至少也要用主键把？
修改重写
从上面的分析来看，大多数的功能代码已经分析完毕了，我们开始着手重写这个复杂的轮子把。重写，当然是先实现底层类比较好。
model的重写
当一个用户的属性来源于多张表的时候，一个模型肯定是不够了，但是laravel的Auth，显然是不方便拓展的。因此，我们只能改写一部分。 我们找到laravel实现的地方！回想开始的配置，默认使用的驱动器是eloquent，类是App\Http\User。 找到实现类Illuminate\Auth\uentUserProvider。里面实现了多种查询方式，那我们发现了一个规律，查询之前，他一定是先创建模型，模型就是我们的类App\Http\User。 比如：
$query = $this->createModel()->newQuery();
foreach ($credentials as $key => $value) {
if (! Str::contains($key, 'password')) {
$query->where($key, $value);
}
}
return $query->first();
找了很久，我发现，我们不好改写这个类，因为这个类并没有用配置去注入，但是，我找到了一条规律，查询之前，必然会先newQuery()，这个方法的调用对象是我们配置的。 于是，我的改写版出路，我改写了App\Http\User的newQuery()
public function newQuery() {
$query = $this->newBaseQueryBuilder();
$builder = new class($query) extends Builder {
/**
* Create a new Eloquent query builder instance.
*
* @param \Illuminate\Database\Query\Builder $query
* @return void
*/
public function __construct(QueryBuilder $query)
{
parent::__construct($query);
}
/**
* Execute the query and get the first result.
*
* @param array $columns
* @return \Illuminate\Database\Eloquent\Model|object|static|null
*/
public function first($columns = ['*']) {
/** @var Model $user */
$user = $this->take(1)->get($columns)->first();
//從別的模型查數據 設置到這個模型裏面
if($user!=null) {
//拓展user的其他屬性
$user->setAttribute('acl', ['dsadas', 'dsadas', 'dsada']);
}
//var_dump($user);exit();
return $user;
}
};
$builder->setModel($this);
return $builder;
}
是不是，用户信息存在于多表的问题就这么简单的解决了。
guard的重写
但是，比如上面的接口，一般调用会很勤快，这个时候，我们还每次用这么乱的资料去查库，是不是会导致db卡IO（并发的时候）。一般情况，我们已经知道了用户的ID，接口一般都会附带用户信息进行请求，不是么？那么，我们很显然，只需要根据ID进行查询用户信息即可。
首先，我们新建类App\Library\Auth\TokenGuard以备接下来使用。
再看之前的TokeGuard类，我们发现他的条件是使用的token进行查询的，我们不妨把他改成主键，但是主键从何而来？所以我们要先获取到user_id。我设想，我的token是通过user_id加密而来，这时候，我只需要解密就好了。
$this->uid = $this->_validateToken($token); //伪代码
public function validate(array $credentials = [])
{
if($this->provider->retrieveById($this->uid)) { //直接改成从ID查询
return true;
}
return false;
}
显然，既然我们已经知道ID，用ID查询岂不美滋滋，如果对性能要求特别高，而且不想在数据库进行查询，完全可以把这个部分实现在redis，这里不是我们的重点，我就不细讲了（实现还是修改newQuery修改成redis查询即可，记得返回Model对象即可）。
AuthManager的重写
既然验证器也写好了，我们肯定要把自己的验证器覆盖。 新建一个类,重写createTokenDriver方法用自己的类覆盖即可
class AuthManager extends \Illuminate\Auth\AuthManager
{
public function createTokenDriver($name, $config)
{
$guard = new TokenGuard(
$this->createUserProvider($config['provider'] ?? null),
$this->app['request']
);
$this->app->refresh('request', $guard, 'setRequest');
return $guard;
}
}
其他配置
最后，我们需要把我们的认证服务加载到内核中来。 重写App\Providers\AuthServiceProvider集成原本的认证类，只需重写registerAuthenticator,其它的功能就照样可以用。
class AuthServiceProvider extends \Illuminate\Auth\AuthServiceProvider
{
protected function registerAuthenticator()
{
$this->app->singleton('auth', function ($app) {
$app['auth.loaded'] = true;
return new \App\Library\Auth\AuthManager($app);
});
$this->app->singleton('auth.driver', function ($app) {
return $app['auth']->guard();
});
}
}
config/app.php 修改
Illuminate\Auth\AuthServiceProvider::class
=》
App\Providers\AuthServiceProvider::class
总结
个人心得
其实个人不太喜欢这种方式，毕竟登录注册这种含有业务逻辑的东西，我觉得封装到框架内部的意义并不大。但是为了偷懒的话，改写复用也是一种方式。
备注
注意，修改密码和更改更新之类的，需要在update之前unset那么其它表的数据，才能进行更新，否则会报字段不存在。
源码位置
一个正在实现的教材管理系统，替俺一个关系很好的老师做的edu_book。 还有公司的一个项目也共用这种方法重写auth，就不能开源了