"Wildcard" Subdomain for Every Tenant

Now, let's talk about subdomains. This is a typical way to structure multi-tenancy projects, and how to separate tenants so every tenant would have a "personal space". Fake, but personal space.

What do I mean by fake? Why is it fake?

Because subdomains can't act as a security filter, it wouldn't be secure enough. For example, we have a tenancy.test domain. And for every tenant/company/team, we create a subdomain like povilas.tenancy.test.

If I take just the URL and filter the data by that URL, anyone could fake my URL without even being logged in. Another way would be to log into another tenant, replace their URL, and land onto my workspace, which is a security issue.

So, in this lesson, we will create subdomains. I will show you how it works, but you need to understand correctly that it is more like the cherry on top, like part of the design of your application, but not the secure authentication of the tenant.

Let's implement these features:

1. Register the subdomain during the registration and then redirect to the correct subdomain.
2. When switching between the tenants, redirect them to their subdomain.

Registering the Subdomain

In the registration form, let's add the input for the subdomain.

resources/views/auth/register.blade.php:

// ...
 
<!-- Email Address -->
<div class="mt-4">
    <x-input-label for="email" :value="__('Email')" />
    <x-text-input id="email" class="block mt-1 w-full" type="email" name="email" :value="old('email')" required autocomplete="username" />
    <x-input-error :messages="$errors->get('email')" class="mt-2" />
</div>
 
<!-- Subdomain -->
<div class="mt-4">
    <x-input-label for="subdomain" :value="__('Subdomain')" />
    <x-text-input id="subdomain" class="block mt-1 mr-2 w-full" type="text" name="subdomain" :value="old('subdomain')" required />
    <x-input-error :messages="$errors->get('subdomain')" class="mt-2" />
</div>
 
<!-- Password -->
 
// ...
</x-guest-layout>

Next, create a subdomain column in the tenants table.

php artisan make:migration "add subdomain to tenants table"

database/migrations/xxx_add_subdomain_to_tenants_table.php:

Schema::table('tenants', function (Blueprint $table) {
    $table->string('subdomain')->unique();
});

app/Models/Tenant.php:

class Tenant extends Model
{
    protected $fillable = [
        'name',
        'subdomain', 
    ];
 
    public function users(): BelongsToMany
    {
        return $this->belongsToMany(User::class);
    }
}

Lastly, when a tenant is being created, and the user is registering, we must do three things:

1. Validate the subdomain for uniqueness
2. Create a tenant with the subdomain
3. Finally, the user must be redirected to the tenant subdomain

app/Http/Controllers/Auth/RegisteredUserController.php:

class RegisteredUserController extends Controller
{
    // ...
 
    public function store(Request $request): RedirectResponse
    {
        $request->validate([
            'name' => ['required', 'string', 'max:255'],
            'email' => ['required', 'string', 'lowercase', 'email', 'max:255', 'unique:'.User::class],
            'password' => ['required', 'confirmed', Rules\Password::defaults()],
            'subdomain' => ['required', 'alpha', 'unique:'.Tenant::class], 
        ]);
 
        $user = User::create([
            'name' => $request->name,
            'email' => $request->email,
            'password' => Hash::make($request->password),
        ]);
 
        $tenant = Tenant::create([
            'name' => $request->name . ' Team',
            'subdomain' => $request->subdomain, 
        ]);
        $tenant->users()->attach($user);
        $user->update(['current_tenant_id' => $tenant->id]);
 
        event(new Registered($user));
 
        Auth::login($user);
 
        return redirect(route('dashboard', absolute: false)); 
        $tenantDomain = str_replace('://', '://' . $request->subdomain . '.', config('app.url')); 
        return redirect($tenantDomain . route('dashboard', absolute: false));
    }
}

Wildcard Subdomain

After registering, we are redirected to the correct subdomain but not logged in correctly. And this is important. For authentication sessions, Laravel saves cookies on your computer based on domain: in this case, domain and subdomain are different.

So, to perform that wildcard subdomain session, we need to set the SESSION_DOMAIN in the .env to your domain.

.env:

// ...
 
SESSION_DRIVER=database
SESSION_LIFETIME=120
SESSION_ENCRYPT=false
SESSION_PATH=/
SESSION_DOMAIN=tenancy.test 
 
// ...

After registering with a new user and different subdomain, we are redirected to the correct subdomain and authenticated.

Subdomain Routing

So, we have that subdomain, but should we do something about it? Should we check that? Should we get that into a variable and then filter some records for it? As I said at the beginning of this lesson, I would advise you on something else.

Laravel has the routing feature of subdomain routing, so we could use that. But we do have the current_tenant_id saved in the database. This is our primary source of security checks, which are the domains active for the user. So, in my case, I recommend not using wild card routing with a domain for multi-tenancy.

But if the user has more than one tenant, when the user changes the tenant, they must be redirected to the tenant's subdomain.

class TenantController extends Controller
{
    public function __invoke($tenantId)
    {
        // Check tenant
        $tenant = auth()->user()->tenants()->findOrFail($tenantId);
 
        // Change tenant
        auth()->user()->update(['current_tenant_id' => $tenant->id]);
 
        // Redirect to dashboard
        return redirect()->route('dashboard'); 
        $tenantDomain = str_replace('://', '://' . $tenant->subdomain . '.', config('app.url')); 
        return redirect($tenantDomain . route('dashboard', absolute: false));
    }
}

But as I said multiple times in this lesson, it's just a nice touch that you visually see what team you are on, but filtering the data is actually performed by the users.current_tenant_id field from the database.