The core content of Laravel framework: detailed analysis of Session source code

What this article brings to you is a detailed analysis of the core content of Laravel framework: Session source code, which has certain reference value. Friends who need it can refer to it and hope to help you. Session module source code analysis

Since HTTP was originally an anonymous and stateless request/response protocol, the server processes the request from the client and sends back a response to the client. In order to provide personalized services to users, modern Web applications often need to identify users in requests or share data among multiple requests of users. Session provides a way to store and share information about users among multiple requests. Laravel handles all kinds of its own Session background drivers through the same readable API.

Drivers supported by Session:

File-saves the Session in storage/framework/sessions.

Cookie-Session is stored in a secure encrypted cookie.

Database-Session is stored in a relational database.

Memcached/redis-Sessions are stored in one of the fast and cache-based storage systems.

Array-Sessions are stored in PHP arrays and will not be persisted.

In this article, let's take a detailed look at the implementation principle of the Session service in Laravel, the components of the Session service and the role of each part, when it was registered in the service container, when the request was enabled for the session, and how to extend the driver for the session.

As mentioned in many previous articles, registering the Session service is registered in the service container through the service provider. Laravel will execute the service provider register method in the providers array in config/app.php in turn to register the services needed by the framework in the startup stage, so it is easy to think that the session service is also registered in the service container at this stage.

'providers' => [ /* * Laravel Framework Service Providers ... */ ...... Illuminate\Session\SessionServiceProvider::class ...... ],

If there is indeed a sessionServiceProvider in providers, let's take a look at its source code and see the registration details of the Session service.

namespace Illuminate\Session; use Illuminate\Support\ServiceProvider; use Illuminate\Session\Middleware\StartSession; class SessionServiceProvider extends ServiceProvider { /** * Register the service provider. * * @return void */ public function register() { $this->registerSessionManager(); $this->registerSessionDriver(); $this->app->singleton(StartSession::class); } /** * Register the session manager instance. * * @return void */ protected function registerSessionManager() { $this->app->singleton('session', function ($app) { return new SessionManager($app); }); } /** * Register the session driver instance. * * @return void */ protected function registerSessionDriver() { $this->app->singleton('session.store', function ($app) { // First, we will create the session manager which is responsible for the // creation of the various session drivers when they are needed by the // application instance, and will resolve them on a lazy load basis. return $app->make('session')->driver(); }); } }

There are three services registered in SessionServiceProvider:

Session service, which is a SessionManager object after parsing, is used to create a session driver and parse the driver (delayed loading) when necessary. In addition, all method calls to access and update session data are implemented by its proxy to the corresponding session driver.

Session.store session driver, an instance of Illuminate\Session\Store, the Store class implements Illuminate \ Contracts \ Session \ Contract, which provides a unified interface for developers to access session data, and the driver accesses session data in different storage media such as database, redis and memcache through different SessionHandler.

StartSession::class middleware provides the ability to open the Session at the beginning of the request, and write the session identifier into the Cookie before sending the response to the client. In addition, as a terminate middleware, it will save the update of the session data in the request to the storage medium in the terminate () method after sending the response to the client.

Creating a session Drive As mentioned above, SessionManager is used to create a session drive, and it defines various drive creators (methods for creating drive instances). From its source code, it is proved that the session drive was created: