Laravel Multitenancy — Part 3
The Middleware that binds them all…
This is a continuation of Laravel Multitenancy Part 2
The fun part. Authenticating the user and dynamically connecting to the user’s tenant’s/organization’s database.
To contact me for any questions, send me a mail at gamerwalt@gmail.com.
I do not use sub-domains for tenants/organizations. I only see it as an aesthetic thing. You can easily detect a user’s organization by using eager loading in Laravel. If you use sub-domains, the logic is the same, simply find the tenant/organization, get the database name and details and connect using the ConnectTenant middleware explained below.
There are many resources on the Internet that touches on registration with Laravel as well as firing queued events. Try https://www.laracasts.com for such lessons. Jeffrey Way is one hell of a teacher.
The User and Tenant Models
Create the models for the user, tenant, tenant_user and the tenant_database. If your Auth is not set to use the user model, please do so now. Plan to use stripe or subscription, use the tenant model to do so. This is because you are not checking the user’s plan, you’re checking the plan of the organization, the tenant.
Controllers
In Laravel, you already have the base controller in the app/http/controllers folder. This is fine and we’ll definitely use this for public facing routes, however you’ll need one more base controller that extends the controller that shipped with laravel.
In my views folder, I have a folder called public and this is where the public views are placed. We are going to have a tenant folder in the views directory and the same goes for that within the controllers directory. Within the new tenant’s folder under controllers, make a new controller called TenantsController, and extend laravel’s default controller. In the tenant’s folder under the views/tenant’s directory, create the dashboard view.
ConnectTenant Middleware
Create this middleware with the “php artisan make:middleware” command. Within this middleware is where the magic happens. Basically, we will check if the user is authenticated, grab the user’s tenant information, determine the database(s) of the tenant and dynamically connect to the tenant. I suggest you use caching for your application and please use memcached or redis. Using memcached or even redis will enable you to use cache tags. This will enable you to have a tag for a tenant as well as tags for models of the tenant. See below for the code of my middleware.
TenantBaseController
This controller will extend laravel’s default controller. Within this class is one single method. The constructor. The constructor will define which middleware to use. In our case, this is the middleware above (ConnectTenant). Other application specific controllers will extend the TenantBaseController and call it’s construct method.
AuthController
This controller should extend laravel’s controller because we have no idea who the user is. What we are doing here is authenticating the user against our user model/table. Do your basic authentication here and if successful, redirect the user to the Dashboard.
DashboardController
This controller should extend TenantBaseController and within its construct method, call the construct method of its parent.
Models
The models of your application should connect directly to the config’s database name. In this case, this is benta_tenant. Below is a sample of one of the models I use that connects to the tenant’s database automatically.
The User model which is used to authenticate a user uses a different connection as you can see below.
In a short while, I will be compiling what I have discussed in here by creating a repository on github. Most of my repositories are private. But I will make this one public.
