Analysis of Session write invalidation caused by extended Laravel default session middleware, laravelsession_php tutorial

Analysis of Session write invalidation caused by extended Laravel default session middleware, Laravelsession

Recently, due to project development needs, mobile phone client and web-side unified use of a set of interfaces, in order to ensure that the session can be normal and in all cases compatible, I would like to be able to change the way SessionID access. By default, all Web sites are implemented via a cookie in the header of the HTTP request, which is associated with the server-side data through the SessionID specified in the cookie to enable session functionality.

However, for mobile clients, the original Cookie may not be supported or blocked depending on the platform's needs, so it is required in development to identify SessionID by adding a request header x-session-token. In the Laravel framework, the implementation Session initialization, read and start, all through illuminate\session\middleware\startsession this middleware implementation, the middleware has a key method GetSession, This method is to get SessionId to tell the session component what credentials to restore session data.

The middleware is registered under the app/http/kernel.php file.

I created a new class to inherit the middleware, while replacing the app/http/kernel.php under the registration of the place, the original GetSession method source code is as follows:

Public Function getsession (Request $request) {$session = $this->manager->driver (); $session->setid ($request- >cookies->get ($session->getname ())); return $session;}

In the new middleware, I changed to:

Public Function getsession (Request $request) {$session = $this->manager->driver ();//Determine if the interface is accessible and choose according to the actual situation SessionID is obtained 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;}

But the trouble comes with it ...

After the modification, push to the branch, before merging to the main development branch, often need to run a unit test, unfortunately, the case of the previous case that the error, the problem is the CSRF component reported token errors, and we have provided in this place token and no two, the problem must be in the Session On

It is worth noting that I modify the code of the middleware, the impact on the framework can be said that there is no, in fact, it is not, because I will create my own middleware code to modify the inheritance of the middleware code consistent also does not help, but strangely, when I put the middleware back to the original middleware does not have this problem.

So I will both normal and abnormal code run once, in the key point debugging, found that the problem is an important property of the middleware $sessionHandled, if the value of false will cause our previous situation. The key is, when the middleware starts, will go handle method, and for the Session of this middleware, the handle method of the first line of code is:

$this->sessionhandled = true;

Interesting ...

We know. The Laravel framework is characterized by its IoC container, which initializes various classes in the framework to implement various dependency injections to ensure loose coupling between components. Middleware is no exception. To be sure, the biggest difference between a singleton and a normal instance is that no matter how many times it is created, the Singleton is always one, and the attribute in the instance is not initialized, so the problem-free middleware is necessarily a singleton, and the middleware I create is just an example of an ordinary class. But in order to know the reason why, I need to confirm my idea (in fact, the solution has come to mind, said later).

So the problem is basically the initialization of the middleware this piece, so have to play the spirit, carefully Laravel the startup code. And the focus here is a class called Illuminate\pipeline\pipeline.

This class has three important methods of send, through, then. Where then is the key to start everything. This class is primarily a piece of work that executes several framework-initiated steps, starting with the components required for the initialization process (request and middleware), followed by a stack of requests through these processing components (a bunch of middleware and routing components), and finally the return processing result (Response).

It can be said that this thing is the core of the Laravel Http part (the amount, is originally Kernel). Then the problem is that the Pipeline then method and its invocation of the Getslice method, directly observe the Getslice method, you can find it is responsible for generating the processing stack, and instantiate the middleware (middleware) class, the entire method code is as follows:

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));}};};}

Notice $this->container->make ($name), which means that it initializes a middleware class, which is simply make, and if it is not a singleton, it repeats new, causing the previous property to be initialized.

Then the solution is obvious, making it a single case.

I added the following line of code to the App/providers/appserviceprovider.php register method to resolve the previous issue:

$this->app->singleton (Sessionstart::class); Sessionstart is my middleware class name.

Above to introduce the extension Laravel default session middleware caused by the session write failure analysis of the entire content, I hope you like.

Articles you may be interested in:

• Client-side workaround for session object invalidation
• Asynchronous HttpContext.Current implements the method of taking value (resolves asynchronous application,session,cache ... Problems such as failure)
• Browser off the session to disable the problem of many ways to solve
• Solution to the problem of IFrame cross-domain and session failure
• Laravel 5 Framework Learning eloquent (Laravel's ORM)
• Laravel 5 Framework Learning Form
• Laravel 5 Framework Study date, Mutator and Scope
• Laravel 5 Framework Learning Form Validation
• Eloquent relationship of Laravel 5 Framework Learning
• Laravel 5 Framework Learning user authentication
• Laravel 5 Framework Primer (i)

http://www.bkjia.com/PHPjc/1089945.html www.bkjia.com true http://www.bkjia.com/PHPjc/1089945.html techarticle about extended Laravel default session middleware caused by the session write failure analysis, laravelsession recently due to project development needs, mobile phone client and web-side unified use a set of ...

