Building membership websites with Laravel and Statamic

Also, ensure passwords points to the correct reset and activation configs:

// config/statamic/users.php
 
'passwords' => [
    'resets' => 'statamic_resets',
    'activations' => 'statamic_activations',
],
php
    
        
        Copy
    
    
        
        Copied!
    

This wires Statamic’s flows to the right broker entries.

After this setup we effectively start using the database with Statamic. So don’t forget to set up your local database and run:

php artisan migrate
bash
    
        
        Copy
    
    
        
        Copied!
    

This creates the tables your auth flows need.

2. Authentication forms conundrum

The easiest way to build auth forms is to use Statamic user tags. The problem is that tags always talk to the user repository set in config/statamic/users.php. By default it is file.

Statamic does allow storing users in a database. That lets you use all user form tags without worrying about auth routes and controllers. However, we run into the same problem I mentioned earlier. Now all users, Statamic editors and app users, get lumped together. I think this is better than flat files, but it still may not fit your project.

If you go this route, you also get the bonus of using Statamic roles and permissions without a separate package, and you can manage app users through the CP. But if you plan to use the Filament admin panel for the app side, it's irrelevant.

So there are trade-offs. But for me, lumping all users together feels a bit icky.

So let’s set this up ourselves. Don’t worry. We won’t write it from scratch.

Using Laravel starter-kit

To set up auth ourselves, the quickest way is to create a fresh Laravel app with a starter-kit and copy what we need for auth. The starter-kit docs also explain guards and scaffolding links you can trace back.

Select the Vue starter-kit. This may help later if you want to set up Vue.js for your app and even turn it into an SPA with Inertia.

Here is what we need to copy:

• Auth folder from app/Http/Controllers.

• Auth folder from app/Http/Requests.

• Auth folder from tests/Feature.

• routes/auth.php and include it in routes/web.php:

  // routes/web.php
   
  require __DIR__.'/auth.php';
  php
      
          
          Copy
      
      
          
          Copied!
      
  

• Dashboard route in routes/web.php.

If you’re not going to use Inertia then update the create methods inside controllers to point to your views. Here is a register controller example:

<?php
 
namespace App\Http\Controllers\Auth;
 
//...
use App\Http\Controllers\Controller;
use Illuminate\View\View;
 
class RegisteredUserController extends Controller
{
    /**
     * Show the registration page.
     */
    public function create(): View
    {
        return view('auth.register');
    }
 
    //...
}
php
    
        
        Copy
    
    
        
        Copied!
    

This returns a Blade view instead of an Inertia response.

Update the User model to enable email verification:

<?php
 
namespace App\Models;
 
use Illuminate\Contracts\Auth\MustVerifyEmail;
// ...
 
class User extends Authenticatable implements MustVerifyEmail
{
    // ...
}
php
    
        
        Copy
    
    
        
        Copied!
    

This makes Laravel send and enforce verification for users.

View templates

I’m not going to walk you through every view template here. Whether you use Livewire, Vue, or React, you can copy auth setup from the Laravel starter-kits. If you’re using Blade with Alpine, here is a community-maintained starter-kit from Laravel Daily.

In Bedrock, I use Blade with Alpine Precognition forms.

Some things to note about Bedrock setup:

• You need to add middleware to all routes where you use a form with Precognition.

• Precognition works with validation rules in the route’s form request. So refactor Controllers to use Form Requests. See form requests.

• Update Controllers to return JsonResponse instead of redirect.

Maybe in the future I’ll update Bedrock with an option to scaffold authentication out of the box and let you pick Alpine.js with Blade or Vue.js with Inertia.

3. Gating Statamic content

You can protect your content per-entry or per-collection.

In Statamic they’re called Protectors.

Protecting an entry

To protect an entry, add a protect variable with a corresponding scheme name.

Statamic comes pre-configured with a logged_in protection scheme. To see all schemes and configure your own, check config/statamic/protect.php.

Here is how your entry might look:

---
 
title: Members Only
 
protect: logged_in
 
---
 
When visiting this entry's URL, logged in users will see it,
 
but logged out users will be redirected to a login page.
yaml
    
        
        Copy
    
    
        
        Copied!
    

This adds a per-entry gate with a simple “logged in” rule.

You can create a Button Group or Select field with a handle protect to let editors toggle this in the control panel instead of editing entries by hand.

Protecting a collection

To protect a whole collection, inject a protect variable to the collection’s YAML config file.

---
 
inject:
 
  protect: logged_in
yaml
    
        
        Copy
    
    
        
        Copied!
    

This applies the same rule to every entry in the collection.

Create a custom protection driver

Default logged_in protection does not enforce verified users. So let’s create a custom protector AuthVerified that extends the Authenticated protector.

// app/Protectors/AuthVerified.php
 
<?php
 
namespace App\Protectors;
 
use Illuminate\Support\Facades\Auth;
use Statamic\Auth\Protect\Protectors\Authenticated;
use Illuminate\Contracts\Auth\MustVerifyEmail;
 
class AuthVerified extends Authenticated
{
    public function protect()
    {
        if (Auth::guest()) {
            abort(redirect($this->getLoginUrl()));
        }
 
        $user = Auth::user();
 
        if ($user instanceof MustVerifyEmail && !$user->hasVerifiedEmail()) {
            abort(redirect(route('verification.notice')));
        }
    }
}
php
    
        
        Copy
    
    
        
        Copied!
    

This blocks unverified users, and it redirects them to the right pages.

Register the driver inside a service provider’s boot method as per docs:

// app/Providers/AppServiceProvider.php
 
use App\Protectors\AuthVerified;
use Statamic\Auth\Protect\ProtectorManager;
 
public function boot(): void
{
    app(ProtectorManager::class)->extend('auth_verified', function ($app) {
        return new AuthVerified();
    });
}
php
    
        
        Copy
    
    
        
        Copied!
    

This makes your new driver available as auth_verified.

Add to the protect.php config file:

// config/statamic/protect.php
 
'schemes' => [
    //...
 
    'logged_in' => [
        'driver' => 'auth',
        'login_url' => '/login',
        'append_redirect' => true,
    ],
 
    'logged_in_verified' => [
        'driver' => 'auth_verified',
        'login_url' => '/login',
        'append_redirect' => true,
    ],
 
    //...
]
php
    
        
        Copy
    
    
        
        Copied!
    

This gives you two choices: logged-in only, or logged-in and verified.

Where to take this next

You now have clean separation between Statamic editors and app members, plus flexible content gates.

If you tried a different approach or found pitfalls I should mention, message me on X. Or if you want me to add auth scaffolding option to Bedrock, let me know that too.

And if you’re building an educational platform, a community, or want to publish members-only content, and looking for help, I’m available for hire.