TP5.1中间件在控制器中是如何使用的？（过程详解）

ThinkPHP5.1中间件在控制器中使用过程

使用中间件的开始以及我的步骤描述，希望可以帮到才学php 或者才学think框架的你们希望能够与你们交流，让自己进步。

中间件在Thinkphp框架中的作用我已经明白了，就是在请求即将达到应用层之前，对用户访问资源时候，产生的header头 或者 用户的请求参数时候输入的post 或get 或者别的请求类型，以及url 路径进行操作，其中包括了前置或者后置操作或者执行顺序等方案。在理解后觉得这个东西在处理用户请求数据的时候有极大的作用，比之直接在控制器或者在行为里面处理好了很多。（于是怀着满满的激动心情阅读5.1的文档手册）。

在阅读完文档后，按照官方手册的方法，在命令行中敲出如下代码:
php think make:middleware Check
这段代码的意思没有任何问题就是生产一个中间件目录以及创建一个新的名字为Check中间件文件
该内容正常完成没有问题

按照文档要求方案粘贴了5.1的文档代码

完全照着手册复制的，没有任何问题，确认进行了保存以及任何错误。

在此确认在我的admin模块根目录下放置了一个名字为 middleware.php的文件 如下图所示

，就这样进行一个注册，那么这个模块下如果想使用中间件，就可以使用了。

然后我在控制器内按照文档手册中的内容，根据控制器中间件内容描述加入了如图所示的代码

,

结果发现，代码没有被执行，纳闷的我摸了摸脑袋，按照我的理解应，如果这么做了的话，应该可以直接应用了才对的，结果对象是个空的。无奈下，按照自己的理解，我在中间件内停止了代码

在看到自己希望看到的内容后，再次测试我的$request。 看到了我期待已久的东西，我的中间件好了

至此以上步骤告诉我，第一步已经完成，我现在可以使用一个中间件做我想做的事情了

第一步 先吧名字变成我想变得 这里有三处改动的地方。

再次刷新后发现依然可以使用，绝对溜溜的跑起来。在这一步中，也坚定了我的一些使用想法，比如创造多个中间件，每个控制器都应该有一个相对应的，在这里执行一些自己象处理的，在看到手册上还可以使用各种其他的方法，包括执行顺序的改变，这让我心中各种意淫。从此代码变得又可以稍微高大上一点了。

第二步 建立功能规则 配合Config配置中的自建文件，对访问进行控制

<?php namespace apphttpmiddleware;
use thinkfacadeConfig;
use thinkfacadeRequest;
/**
登陆接口通用数据配置检测*/
class AdminLoginCheck
{
/**
 * handle  重写处理请求对象的操作函数
 * @param  object Request $request 请求对象
 * @param  object \Closure $next 响应对象
 * @return array 错误返回的信息
 *         code 返回码
 *         msg 返回信息
 *         data 返回数据
 * @return  object 响应对象
 */
public function handle($request, \Closure $next)
{
    // 检测配置，查看该接口服务是否被暂停使用
    if (true !== Config::get(Request::module().&#39;.&#39;.Request::action().&#39;.&#39;.Request::action().&#39;_api&#39;))
    // 如果结果不符合要求则返回错误信息
    exit(json_encode([&#39;code&#39;=>1,'msg'=>'Interface_Pause_service','data'=>'']));
    // 检测配置，是否执行请求验证类型
    if (false !== Config::get(Request::module().'.'.Request::action().'.'.Request::action().'_request'))
    {

        // 登陆请求规则，传入相应方法，查看该接口是否符合请求类需
        $res = self::loginRequestRole(Request::action());
        // 如果结果不符合要求则返回错误信息
        if (true !== $res) exit(json_encode(['code'=>1,'msg'=>'Request_Type_Not_Matching','data'=>'']));
    }
    // 检测配置，是否执行地址限制验证
    if (false !== Config::get(Request::module().'.'.Request::action().'.'.Request::action().'_address'))
    {
        // 客户端访问地址限制请求规则
        $res = self::loginAddressDispose(Request::ip());
        // 如果结果不符合要求则返回错误信息
        if (true !== $res) exit(json_encode(['code'=>1,'msg'=>'Address_Not_Access','data'=>'']));
    }
    // 格式化与处理前台参数
    $request = self::loginParamDispose(Request::action(),$request);
    
    // 继续执行进入到控制器
    return $next($request);
}

/**
 * loginRequestRole 请求类型验证
 * @param  string $scene 根据路径传入方法名称
 * @return bool 验证用户访问的接口是否符合预设的请求要求
 */
protected static function loginRequestRole($scene)
{
    switch ($scene)
    {
        // 登陆页面请求验证
        case 'index':
            if (Request::isGet()) return true;
            else return false;
            break;
        // 登陆接口请求验证
        case 'login':
            if (Request::isPost() || Request::isAjax() || Request::isPjax()) return true;
            else return false;
            break;
        // 登陆接口请求验证
        case 'resetPassword':
            if (Request::isPost() || Request::isAjax() || Request::isPjax()) return true;
            else return false;
            break;
        // 默认验证或者不存在的场景返回
        default:
            return false;
            break;
    }
}

/**
 * loginAddressDispose 地址是否允许访问
 * @param  string $address 需要传入一个address地址
 * @return string     返回错误信息
 * @return bool     检测正确返回真
 */
protected static function loginAddressDispose($address)
{
    // 读取配置内的设置参数
    $data = Config::get(Request::module().'.'.Request::action().'.'.Request::action().'_address_data');
    // 如果配置信息address列表为空则返回不能访问
    if (empty($data)) return false;
    // 循环地址列表信息解开连续address地址列表
    foreach ($data as $key => $val) { if ($val == $address) return true; }
    // 如果继续执行下去依然没有 返回不能访问
    return false;
}

/**
 * loginParamDispose post内容与格式处理
 * @param  string $scene 需要前往的接口名称
 * @param  object $request 请求的对象内容
 * @return object 返回处理过的请求对象
 */
protected static function loginParamDispose($scene,$request)
{
    switch ($scene)
    {
        // 登陆页面
        case 'index':
            break;
        // 登陆接口请求参数处理
        case 'login':
            // 前台用户传入的参数进行调整转换
            $request->username = $request->param('user');
            $request->password = $request->param('pass');
            $request->captcha = $request->param('code');
            // 对记住我进行处理
            $remember = $request->param('remember');
            if (null === $remember) $request->remember = 'shut';
            else $request->remember = 'open';
            break;
        // 重置密码接口参数处理
        case 'resetPassword':
            // 前台用户传入的参数进行调整转换
            $request->username = $request->param('user');
            $request->phone = $request->param('mobile');
            $request->phonecode = $request->param('code');
            $request->password = $request->param('pass');
            $request->repassword = $request->param('repass');
            break;
        // 默认接口或者不存在的场景返回
        default:
            break;
    }
    return $request;
}
}

至此一个简单的中间件检测工作完成，当然，这种写法是由固定要求的 比如在多个控制访问中，接口的统一带上api 请求的统一带上request这样不管怎么样都可以正常使用

单独要说的两个问题，就是其实可以将配置中需要用到的内容继续进行

第一个问题是 中间件并不是万能的，只能做一些请求处理，而且是必须带参的，千万不要去做不符合要求的高级验证，这里最多的只是做一些前置验证，让数据安全或者让数据饱满

第二给问题是 不要在中间件中尝试做不合时宜的动作，不要在中间件中执行超级复杂的代码，如果你拿中间件做超级复杂的代码或者超长运算，我估计可以坑死很多人，这里所说包括了尽量少使用自己函数库定义的函数代码验证 有些避不开的还是可以使用的，比如密码加密这种类似的代码