最近由于项目开发需要，手机客户端和网页端统一使用一套接口，为保证 会话（Session） 能够正常且在各类情况下兼容，我希望能够改变 SessionID 的获取方式。默认情况下，所有网站都是通过 HTTP 请求的 Header 头部中的 Cookie 实现的，通过 Cookie 中指定的 SessionID 来关联到服务端对应数据，从而实现会话功能。
但对于手机客户端，可能并不会支持原始的 Cookie，亦或者根据平台需要而屏蔽，因此开发中要求通过增加一个请求头 X-Session-Token 来标识 SessionID。在 Laravel 框架中，实现 Session 初始化、读取和启动，都是通过 Illuminate\Session\Middleware\StartSession 这个中间件实现的，该中间件有一个关键方法 getSession ，这个方法就是获取 SessionId 从而告知 Session 组件以什么凭据恢复 Session 数据。
该中间件注册于 app/Http/Kernel.php 文件下。
我新建了一个类继承该中间件，同时替换了在 app/Http/Kernel.php 下的注册的地方，原来的 getSession 方法源码如下：
public function getSession(Request $request)
{
$session = $this->manager->driver();
$session->setId($request->cookies->get($session->getName()));
return $session;
}
在新的中间件中，我修改为：
public function getSession(Request $request)
{
$session = $this->manager->driver();
// 判断是否是接口访问并根据实际情况选择 SessionID 的获取方式
if ($request->headers->has('x-session-token')) {
$sessionId = $request->headers->has('x-session-token');
} else {
$sessionId = $request->cookies->get($session->getName());
}
$session->setId($sessionId);
return $session;
}
但是麻烦也随之而来。。。
修改完后，推送至分支，在合并至主开发分支之前往往需要跑一下单元测试，不幸的是，之前通过的 Case 这回竟然报错，问题是 CSRF 组件 报出 Token 错误，而我们在这一处提供的 Token 跟平时并无二致，问题肯定出在 Session 上。
值得注意的是，我修改中间件的代码，对框架的影响可以说根本没有，事实上也确实没有，因为我将我自己创建的中间件代码修改成继承的中间件代码一致也无济于事，但奇怪的是，在我将中间件换回原来的中间件就没有这个问题。
于是我将正常情况下和非正常情况下的代码都跑了一遍，在关键处断点调试，发现问题出在中间件的一个重要属性 $sessionHandled ， 若该值为 false 则会引起我们之前的状况。关键在于，中间件启动之时，都会走 handle 方法，而对于 Session 这个中间件， handle 方法的第一行代码就是：
$this->sessionHandled = true;
Interesting。。。
我们知道。Laravel 框架的特色是其 IoC 容器，框架中初始化各种类都是由其负责以实现各种依赖注入，以保证组件间的松耦合。中间件定然不例外。要知道，单例和普通实例最大的区别在于无论创建多少次，单例永远都是一个，实例中的属性不会被初始化，因此无问题的中间件必然是一个单例，而我自己创建的中间件只是个普通的类的实例。但本着知其然更要知其所以然，我需要确认我这一想法（其实解决办法已经想到了，后面说）。
那么问题大致就在于初始化中间件这块了，于是不得不打起精神，仔细理一下 Laravel 的启动代码。而这里面的重点，在于一个叫 Illuminate\Pipeline\Pipeline 的类。
这个类有三个重要方法 send 、 through 、 then 。其中 then 是开始一切的钥匙。这个类主要是连续执行几个框架启动步骤的玩意儿，首先是初始化处理过程需要的组件（Request 和 中间件），其次是将请求通过这些处理组件构成的堆栈（一堆中间件和路由派发组件），最后是返回处理结果（Response）。
可以说这玩意儿是 Laravel Http 部分的核心（额，，本来就是 Kernel）。那么之前的问题就在于 Pipeline 的 then 方法和其调用的 getSlice 方法，直接观察 getSlice 方法，可以发现它负责的是生成处理堆栈，并实例化 Middleware （中间件）类，整个方法代码如下：
protected function getSlice()
{
return function ($stack, $pipe) {
return function ($passable) use ($stack, $pipe) {
if ($pipe instanceof Closure) {
return call_user_func($pipe, $passable, $stack);
} else {
list($name, $parameters) = $this->parsePipeString($pipe);
return call_user_func_array([$this->container->make($name), $this->method],
array_merge([$passable, $stack], $parameters));
}
};
};
}
可以注意到 $this->container->make($name) ，这意味着其初始化一个中间件类，单纯的就是 make，若其不是单例则反复 new ，导致之前的属性被初始化。
那么解决办法也显而易见面，使其成为一个单例。
我在 app/Providers/AppServiceProvider.php 的 register 方法中添加如下一行代码，就解决了之前的问题：
$this->app->singleton(SessionStart::class); // SessionStart 是我那个中间件类名
以上给大家介绍了扩展 Laravel 默认 Session 中间件导致的 Session 写入失效问题分析的全部内容，希望大家喜欢。
以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索laravel_session失效
aravel中间件
laravel中间件session、laravel session 失效、laravel 写入session、laravel 中间件、laravel 中间件使用，以便于您获取更多的相关知识。