Laravel Unwrapped: Session, Auth and Cache

In recent years, Laravel has become one of the most prominent frameworks software engineers use for building their web applications. Similar to the popularity that CodeIgniter enjoyed in its heyday, Laravel has been lauded for its ease-of-use, friendliness to beginners and its adherence to industry standards.

Introduction

One thing though that not a lot of programmers take advantage of is Laravel's component-based system. Since its conversion to composer-powered components, Laravel 4 has become a very modular system, similar to the verbosity of more mature frameworks like Symfony. This is called the Illuminate group of components, which in my opinion, is not the actual framework itself, but is a compilation of libraries that a framework can potentially use. Laravel's actual framework is represented by the Laravel skeleton application (found on the laravel/laravel GitHub repository) that makes use of these components to build a web application.

In this tutorial, we'll be diving into a group of these components, learning how they work, how they're used by the framework, and how we can extend their functionality.

The Session Component

The Laravel Session component handles sessions for the web application. It makes use of a driver-based system called the Laravel Manager, which acts as both a factory and a wrapper for whichever driver is set in the configuration file. As of this writing, the Session component has drivers for:

  • file - a file-based session driver where session data is saved in an encrypted file.
  • cookie - a cookie-based session driver where session data is encrypted in the user's cookies.
  • database - session data is saved in whichever database is configured for the application.
  • apc - session data is saved in APC.
  • memcached - session data is saved in Memcached.
  • redis - session data is saved in Redis.
  • array - session data is saved in a PHP array. Take note that the array session driver does not support persistence and is usually only used in console commands.

Service Providers

Most Laravel users don't realize but a big part of how Laravel works, is within its service providers. They are essentially bootstrap files for each component and they are abstracted enough so users can bootstrap any components, in any way.

A rough explanation of how this works is below:

  1. The Laravel Application component is initiated. This is the main driver of the whole framework, responsible for handling the HTTP Request, running the service providers, as well as acting as a dependency container for the framework.
  2. Once a service provider is ran, its register method is called. This allows us to instantiate whichever component we want.
    • Keep in mind that all service providers have access to the main Laravel application (via $this->app), which would let service providers push instances of the resolved classes into the dependency container.
  3. Once these dependencies are loaded, we should be free to use them by calling on the container, for example, via Laravel's Facade system, App::make.

Going back to Sessions, let's take a quick look at the SessionServiceProivider:

These two methods are called by the register() function. The first one, registerSessionManager(), is called to initially register the SessionManager. This class extends the Manager that I mentioned on top. The second one, registerSessionDriver() registers a session handler for the manager, based on what we have configured. This eventually calls this method in the Illuminate\Support\Manager class:

From here, we can see that based on the name of the driver, from the configuration file, a specific method is called. So, if we have it configured to use the file session handler, it will call this method in the SessionManager class:

The driver class is then injected into a Store class, which is responsible for calling the actual session methods. This lets us actually separate the implementation of the SessionHandlerInterface from the SPL into the drivers, the Store class facilitates it.

Creating Our Own Session Handler

Let's create our own Session Handler, a MongoDB Session handler. First off, we'll need to create a MongoSessionHandler inside a newly installed Laravel project instance. (We'll be borrowing heavily from Symfony\Component\HttpFoundation\Session\Storage\Handler\MongoDbSessionHandler).:

You should save this in the vendor/laravel/framework/src/Illuminate/Session folder. For the purposes of this project, we'll put it here, but ideally this file should be within its own library namespace.

Next, we need to make sure that the Manager class can call this driver. We can do this by utilizing the Manager::extend method. Open vendor/laravel/framework/src/Illuminate/Session/SessionServiceProvider.php and add the following code. Ideally, we should be extending the service provider, but that is outside the scope of this tutorial.

Make sure to update the register() method to call this method:

Next, we need to define the Mongo DB configuration. Open app/config/session.php and define the following configuration settings:

While we're on this file, we should also update the driver configuration up top:

Now, try and access the main page (usually, localhost/somefolder/public). If this page loads without showing the WHOOPS page, then congratulations, we've successfully created a brand new session driver! Test it out by setting some dummy data on the session, via Session::set() and then echoing it back via Session::get().

The Auth Component

The Laravel Auth component handles user authentication for the framework, as well as password management. What the Laravel component has done here is to create an abstract interpretation of the typical user-management system which is usable in most web applications, which in turn helps the programmer easily implement a login system. Like the Session component, it also makes use of the Laravel Manager. Currently, the Auth component has drivers for:

  • eloquent - this makes use of Laravel's built-in ORM called Eloquent. It also utilizes the pre-made User.php class inside the models folder.
  • database - this uses whichever database connection is configured by default. It makes use of a GenericUser class for accessing the user data.

Since this follows the same implementation as the Session component, the service provider is very similar to what we've seen on top:

Here, we can see that it basically creates an AuthManager class that wraps around whichever driver we're using, as well as acting as a factory for it. Inside the AuthManager, it again creates the appropriate driver, wrapped around a Guard class, which acts the same way as the Store class from Session.

Creating Our Own Auth Handler

Like before, let's start by creating a MongoUserProvider:

It's important to take note here that I'm not checking against a hashed password, this was done for simplicity's sake to make it easier on our part to create dummy data and test this later. In production code, you need to make sure to hash the password. Check out the Illuminate\Auth\DatabaseUserProvider class for a great example on how to do this.

Afterwards, we need to register our custom driver callback on the AuthManager. To do so, we need to update the service provider's register method:

Lastly, we also need to update the auth.php configuration file to make use of the Mongo driver, as well as provide it the proper Mongo configuration values:

Testing this is a little trickier, to do so, use the Mongo DB CLI to insert a new user into the collection:

Now, test it out by trying an Auth::validate method call:

This should dump a bool(true). If it does, then we've successfully created our own Auth driver!

The Cache Component

The Laravel Cache component handles caching mechanisms for use in the framework. Like both of the components that we've discussed, it also makes use of the Laravel Manager (Are you noticing a pattern?). The Cache component has drivers for:

  • apc
  • memcached
  • redis
  • file - a file-based cache. Data is saved into the app/storage/cache path.
  • database - database-based cache. Data is saved into rows into the database. The database schema is described in the Laravel Documentation.
  • array - data is "cached" in an array. Keep in mind that the array cache is not persistent and is cleared on every page load.

Since this follows the same implementation as both components that we've discussed, you can safely assume that the service provider is fairly similar:

The register() method here creates a CacheManager, that again acts as a wrapper and factory for the drivers. Within the manager, it wraps the driver around a Repository class, similar to the Store and Guard classes.

Creating Our Own Cache Handler

Create the MongoStore, which should extend the Illuminate\Cache\StoreInterface:

We'll also need to add the Mongo callback again to the manager:

Lastly, we'll need to update the cache.php config file:

Now, attempt to use the Cache::put() and Cache::get() methods. If done correctly, we should be able to use MongoDB to cache the data!

Conclusion

In this tutorial, we learned about the following:

  • Laravel's component-based system called Illuminate, which is used by the Laravel framework.
  • Laravel Service Providers and a little bit about how they work.
  • Laravel's Manager system, which acts as both a wrapper and factory for the drivers.
  • Session, Auth and Cache components and how to create new drivers for each.
  • Store, Guard and Repository libraries which utilize these drivers.

Hopefully this helps programmers create their own drivers and extend the current functionality of the Laravel framework.

Tags:

Comments

Related Articles