The User Model and Migration

When you create a new Laravel application, the first migration and model you’ll see are the create_users_table migration and the App\User model. Example 9-1 shows, straight from the migration, the fields you’ll get in your users table.

Schema::create('users', function (Blueprint $table) {
    $table->increments('id');
    $table->string('name');
    $table->string('email')->unique();
    $table->string('password');
    $table->rememberToken();
    $table->timestamps();
});

We have an autoincrementing primary key ID, a name, a unique email, a password, a “remember me” token, and created and modified timestamps. This covers everything you need to handle basic user authentication in most apps.

The User model is a bit more complex, as you can see in Example 9-2. The App\User class itself is simple, but it extends the Illuminate\Foundation\Auth\User class, which pulls in several traits.

<?php
// App\User

namespace App;

use Illuminate\Notifications\Notifiable;
use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    use Notifiable;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];
}

<?php
// Illuminate\Foundation\Auth\User

namespace Illuminate\Foundation\Auth;

use Illuminate\Auth\Authenticatable;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Auth\Passwords\CanResetPassword;
use Illuminate\Foundation\Auth\Access\Authorizable;
use Illuminate\Contracts\Auth\Authenticatable as AuthenticatableContract;
use Illuminate\Contracts\Auth\Access\Authorizable as AuthorizableContract;
use Illuminate\Contracts\Auth\CanResetPassword as CanResetPasswordContract;

class User extends Model implements
    AuthenticatableContract,
    AuthorizableContract,
    CanResetPasswordContract
{
    use Authenticatable, Authorizable, CanResetPassword;
}

So, what can we learn from this model? First, users live in the users table; Laravel will infer this from the class name. We are able to fill out the name, email, and password properties when creating a new user, and the password and remember_token properties are excluded when outputting the user as JSON. Looking good so far.

We also can see from the contracts and the traits in the Illuminate\Foundation\Auth verison of User that there are some features in the framework (the ability to authenticate, to authorize, and to reset passwords) that theoretically could be applied to other models, not just the User model, and that could be applied individually or together.

The Authenticatable contract requires methods (getAuthIdentifier(), etc.) that allow the framework to authenticate instances of this model to the auth system; the Authenticatable trait includes the methods necessary to satisfy that contract with an average Eloquent model.

The Authorizable contract requires a method (can()) that allows the framework to authorize instances of this model for their access permissions in different contexts. Unsurprisingly, the Authorizable trait provides methods that will satisfy the Authorizable contract for an average Eloquent model.

And finally, the CanResetPassword contract requires methods (getEmailForPasswordReset(), sendPasswordResetNotification()) that allow the framework to, you guessed it, reset the password of any entity that satisfies this contract. The CanResetPassword trait provides methods to satisfy that contract for an average Eloquent model.

At this point, we have the ability to easily represent an individual user in the database (with the migration), and to pull them out with a model instance that can be authenticated (logged in and out), authorized (checked for access permissions to a particular resource), and sent a password reset email.

Using the auth() Global Helper and the Auth Facade

The auth() global helper is the easiest way to interact with the status of the authenticated user throughout your app. You can also inject an instance of Illuminate\Auth\AuthManager and get the same functionality, or use the Auth facade.

The most common usages are to check whether a user is logged in (auth()->check() returns true if the current user is logged in; auth()->guest() returns true if the user is not logged in) and to get the currently logged-in user (use auth()->user(), or auth()->id() for just the ID; both return null if no user is logged in).

Take a look at Example 9-3 for a sample usage of the global helper in a controller.

public function dashboard()
{
    if (auth()->guest()) {
        return redirect('sign-up');
    }

    return view('dashboard')
        ->with('user', auth()->user());
}

The next section is going to go into a little bit of depth of how the auth system works behind the scenes. It’s useful information but not vital, so if you want to skip it now, check out the next section, “The Auth Scaffold”.

The Auth Controllers

So, how do we actually log users in? And how do we trigger those password resets?

It all happens in the Auth-namespaced controllers: RegisterController, LoginController, ResetPasswordController, and ForgotPasswordController.

...
class RegisterController extends Controller
{
    use RegistersUsers;

    protected $redirectTo = '/home';

    ...

    protected function validator(array $data)
    {
        return Validator::make($data, [
            'name' => 'required|string|max:255',
            'email' => 'required|string|email|max:255|unique:users',
            'password' => 'required|string|min:6|confirmed',
        ]);
    }

    protected function create(array $data)
    {
        return User::create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => Hash::make($data['password']),
        ]);
    }
}

Auth::routes()

Now that we have the auth controllers providing some methods for a series of pre-defined routes, we’ll want our users to actually be able to hit those routes. We could add all these routes manually to routes/web.php, but there’s already a convenience tool for that, called Auth::routes():

// routes/web.php
Auth::routes();

As you can probably guess, Auth::routes() brings in a bundle of predefined routes to your routes file. In Example 9-5 you can see the routes that are actually being defined there.

// Authentication Routes...
$this->get('login', 'Auth\LoginController@showLoginForm')->name('login');
$this->post('login', 'Auth\LoginController@login');
$this->post('logout', 'Auth\LoginController@logout')->name('logout');

// Registration Routes...
$this->get('register', 'Auth\RegisterController@showRegistrationForm')
    ->name('register');
$this->post('register', 'Auth\RegisterController@register');

// Password Reset Routes...
$this->get('password/reset', 'Auth\ForgotPasswordController@showLinkRequestForm')
    ->name('password.request');
$this->post('password/email', 'Auth\ForgotPasswordController@sendResetLinkEmail')
    ->name('password.email');
$this->get('password/reset/{token}', 'Auth\ResetPasswordController@showResetForm')
    ->name('password.reset');
$this->post('password/reset', 'Auth\ResetPasswordController@reset');

// If email verification is enabled
$this->get('email/verify', 'Auth\VerificationController@show')
    ->name('verification.notice');
$this->get('email/verify/{id}', 'Auth\VerificationController@verify')
    ->name('verification.verify');
$this->get('email/resend', 'Auth\VerificationController@resend')
    ->name('verification.resend');

Basically, Auth::routes() includes the routes for authentication, registration, and password resets. As you can see, there are also optional routes for email verification, which was introduced in Laravel 5.7.

To enable Laravel’s email verification service, which requires new users to verify they have access to the email address they signed up with, update your Auth::routes call to enable it:

Auth::routes(['verify' => true]);

The Auth Scaffold

At this point you have a migration, a model, controllers, and routes for your authentication system. But what about your views?

Laravel handles that by providing an auth scaffold (available since Laravel 5.2), which is intended to be run on a new application and provide you with even more skeleton code to get your auth system running quickly.

The auth scaffold takes care of adding Auth::routes() to your routes file, adds a view for each route, and creates a HomeController to serve as the landing page for logged-in users; it also routes to the index() method of HomeController at the /home URI.

Just run php artisan make:auth, and the following files will be made available to you:

app/Http/Controllers/HomeController.php
resources/views/auth/login.blade.php
resources/views/auth/register.blade.php
resources/views/auth/verify.blade.php
resources/views/auth/passwords/email.blade.php
resources/views/auth/passwords/reset.blade.php
resources/views/layouts/app.blade.php
resources/views/home.blade.php

At this point, you have / returning the welcome view, /home returning the home view, and a series of auth routes for login, logout, registration, and password reset pointing to the auth controllers. Each of the seeded views has Bootstrap-based layouts and form fields for all necessary fields for login, registration, and password reset, and they already point to the correct routes.

At this point, you have all of the pieces in place for every step of the normal user registration and authentication flow. You can tweak all you want, but you’re entirely ready to register and authenticate users.

Let’s review quickly the steps from new site to full authentication system:

laravel new MyApp
cd MyApp
# edit your .env file to specify the correct database connection details
php artisan make:auth
php artisan migrate

That’s it. Run those commands, and you will have a landing page and a bootstrap-based user registration, login, logout, and password reset system, with a basic landing page for all authenticated users.

“Remember Me”

The auth scaffold has this implemented out of the box, but it’s still worth learning how it works and how to use it on your own. If you want to implement a “remember me”–style long-lived access token, make sure you have a remember_token column on your users table (which you will if you used the default migration).

When you’re normally logging in a user (and this is how the LoginController does it, with the AuthenticatesUsers trait), you’ll “attempt” an authentication with the user-provided information, like in Example 9-6.

if (auth()->attempt([
    'email' => request()->input('email'),
    'password' => request()->input('password'),
    ])) {
    // Handle the successful login
}

This provides you with a user login that lasts as long as the user’s session. If you want Laravel to extend the login indefinitely using cookies (as long as the user is on the same computer and doesn’t log out), you can pass a boolean true as the second parameter of the auth()->attempt() method. Take a look at Example 9-7 to see what that request looks like.

if (auth()->attempt([
    'email' => request()->input('email'),
    'password' => request()->input('password'),
    ]), request()->filled('remember')) {
    // Handle the successful login
}

You can see that we checked whether the input has a non-empty (“filled”) remember property, which will return a boolean. This allows our users to decide if they want to be remembered with a checkbox in the login form.

And later, if you need to manually check whether the current user was authenticated by a remember token, there’s a method for that: auth()->viaRemember() returns a boolean indicating whether or not the current user authenticated via a remember token. This will allow you to prevent certain higher-sensitivity features from being accessible by remember token, and you can require users to reenter their passwords.

Manually Authenticating Users

The most common case for user authentication is that you’ll allow the users to provide their credentials, and then use auth()->attempt() to see whether the provided credentials match any real users. If so, you log them in.

But sometimes there are contexts where it’s valuable for you to be able to choose to log a user in on your own. For example, you may want to allow admin users to switch users.

There are four methods that make this possible. First, you can just pass a user ID:

auth()->loginUsingId(5);

Second, you can pass a User object (or any other object that implements the Illuminate\Contracts\Auth\Authenticatable contract):

auth()->login($user);

And third and fourth, you can choose to authenticate the given user for only the current request, which won’t impact your session or cookies at all, using once and onceUsingId:

auth()->once(['username' => 'mattstauffer']);
// or
auth()->onceUsingId(5);

Note that the array you pass to the once() method can contain any key/value pairs to uniquely identify the user you’d like to authenticate as. You can even pass multiple keys and values, if it’s what is appropriate for your project. For example:

auth()->once([
    'last_name' => 'Stauffer',
    'zip_code' => 90210,
])

Manually Logging Out a User

If you ever need to log out a user manually, just call logout():

auth()->logout();

'web' => [
    // ...
    \Illuminate\Session\Middleware\AuthenticateSession::class,
],

auth()->logoutOtherDevices($password);

Auth Middleware

In Example 9-3, you saw how to check whether visitors are logged in and redirect them if not. You could perform these sorts of checks on every route in your application, but it would very quickly get tedious. It turns out that route middleware (see Chapter 10 to learn more about how they work) are a perfect fit for restricting certain routes to guests or to authenticated users.

Once again, Laravel comes with the middleware we need to do this out of the box. You can see which route middleware you have defined in App\Http\Kernel:

protected $routeMiddleware = [
    'auth' => \Illuminate\Auth\Middleware\Authenticate::class,
    'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
    'bindings' => \Illuminate\Routing\Middleware\SubstituteBindings::class,
    'cache.headers' => \Illuminate\Http\Middleware\SetCacheHeaders::class,
    'can' => \Illuminate\Auth\Middleware\Authorize::class,
    'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
    'signed' => \Illuminate\Routing\Middleware\ValidateSignature::class,
    'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class,
    'verified' => \Illuminate\Auth\Middleware\EnsureEmailIsVerified::class,
];

Four of the default route middleware are authentication-related:

• auth restricts route access to authenticated users

• auth.basic restricts access to authenticated users using HTTP Basic Authentication

• guest restricts access to unauthenticated users

• can is used for authorizing user access to given routes

It’s most common to use auth for your authenticated-user-only sections and guest for any routes you don’t want authenticated users to see (like the login form). auth.basic is a much less commonly used middleware for authenticating via request headers.

Example 9-8 shows an example of a few routes protected by the auth middleware.

Route::middleware('auth')->group(function () {
    Route::get('account', 'AccountController@dashboard');
});

Route::get('login', 'Auth\LoginController@getLogin')->middleware('guest');

Email Verification

Laravel 5.7 introduced a new feature that makes it possible to require a user to verify that they have access to the email address they registered with.

In order to enable email verification, update your App\User and make it implement the Illuminate\Contracts\Auth\MustVerifyEmail contract.

class User extends Authenticatable implements MustVerifyEmail
{
    use Notifiable;

    // ...
}

The user table must also contain a nullable timestamp column named email_verified_at, which the new default CreateUsersTable migration will have already provided for you in apps created in 5.7 or later.

You’ll also need to do one more thing: enable the email verification routes in your controller. The easiest method is to use Auth::routes in your routes file with the verify parameter set to true:

Auth::routes(['verify' => true]);

Now, you can protect any routes you’d like from being accessed by any users who haven’t verified their email address:

Route::get('posts/create', function () {
    // Only verified users may enter...
})->middleware('verified');

You can customize the route where users are redirected after verifying in your VerificationController:

protected $redirectTo = '/profile';

Blade Authentication Directives

If you want to check against a user’s authentication, not at the route level but in your views, you can, with @auth and @guest:

@auth
    // The user is authenticated
@endauth

@guest
    // The user is not authenticated
@endguest

You can also specify which guard you’d like to use with both methods by passing the guard name as a parameter:

@auth('trainees')
    // The user is authenticated...
@endauth

@guest('trainees')
    // The user is not authenticated...
@endguest

Guards

Every aspect of Laravel’s authentication system is routed through something called a guard. Each guard is a combination of two pieces: a driver that defines how it persists and retrieves the authentication state (for example, session), and a provider that allows you to get a user by certain criteria (for example, users).

Out of the box Laravel has two guards: web and api. web is the more traditional authentication style, using the session driver and the basic user provider. api also uses the same user provider, but it uses the token driver instead of the session to authenticate each request.

You’d change drivers if you wanted to handle the identification and persistence of a user’s identity differently (for example, changing from a long-running session to a provided-every-page-load token), and you’d change providers if you wanted to change the storage type or retrieval methods for your users (for example, moving to storing your users in Mongo instead of MySQL).

    'defaults' => [
        'guard' => 'web', // Change the default here
        'passwords' => 'users',
    ],

$apiUser = auth()->guard('api')->user();

    'guards' => [
        'trainees' => [
            'driver' => 'session',
            'provider' => 'trainees',
        ],
    ],

public function boot()
{
    $this->registerPolicies();

    Auth::viaRequest('token-hash', function ($request) {
        return User::where('token-hash', $request->token)->first();
    });
}

    'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model' => App\User::class,
        ],

        'trainees' => [
            'driver' => 'eloquent',
            'model' => App\Trainee::class,
        ],
    ],

Route::middleware('auth:trainees')->group(function () {
    // Trainee-only routes here
});

auth()->provider('riak', function ($app, array $config) {
    // Return an instance of Illuminate\Contracts\Auth\UserProvider...
    return new RiakUserProvider($app['riak.connection']);
});

Auth Events

We’ll talk more about events in Chapter 16, but Laravel’s event system is a basic pub/sub framework. There are system- and user-generated events that are broadcast, and the user has the ability to create event listeners that do certain things in response to certain events.

So, what if you wanted to send a ping to a particular security service every time a user was locked out after too many failed login attempts? Maybe this service watches out for a certain number of failed logins from certain geographic regions, or something else. You could, of course, inject a call in the appropriate controller. But with events, you can just create an event listener that listens to the “user locked out” event, and register that.

Take a look at Example 9-9 to see all of the events that the authentication system emits.

protected $listen = [
    'Illuminate\Auth\Events\Registered' => [],
    'Illuminate\Auth\Events\Attempting' => [],
    'Illuminate\Auth\Events\Authenticated' => [],
    'Illuminate\Auth\Events\Login' => [],
    'Illuminate\Auth\Events\Failed' => [],
    'Illuminate\Auth\Events\Logout' => [],
    'Illuminate\Auth\Events\Lockout' => [],
    'Illuminate\Auth\Events\PasswordReset' => [],
];

As you can see, there are listeners for “user registered”, “user attempting login,” “user authenticated,” “successful login,” “failed login”, “logout,” “lockout,” and “password reset.” To learn more about how to build event listeners for these events, check out Chapter 16.

Authorization (ACL) and Roles

Finally, let’s cover Laravel’s authorization system. It enables you to determine whether a user is authorized to do a particular thing, which you’ll check using a few primary verbs: can, cannot, allows, and denies. The access control list (ACL) system was introduced in Laravel 5.2.

Most of this authorization control will be performed using the Gate facade, but there are also convenience helpers in your controllers, on the User model, as middleware, and available as Blade directives. Take a look at this example to get a taste of what we’ll be able to do:

if (Gate::denies('edit-contact', $contact)) {
    abort(403);
}

if (! Gate::allows('create-contact', Contact::class)) {
    abort(403);
}

class AuthServiceProvider extends ServiceProvider
{
    public function boot()
    {
        $this->registerPolicies();

        Gate::define('update-contact', function ($user, $contact) {
            return $user->id == $contact->user_id;
        });
    }
}

$gate->define('update-contact', 'ContactACLChecker@updateContact');

if (Gate::allows('update-contact', $contact)) {
    // Update contact
}

// or...
if (Gate::denies('update-contact', $contact)) {
    abort(403);
}

// Definition
Gate::define('add-contact-to-group', function ($user, $contact, $group) {
    return $user->id == $contact->user_id && $user->id == $group->user_id;
});

// Usage
if (Gate::denies('add-contact-to-group', [$contact, $group])) {
    abort(403);
}

if (Gate::forUser($user)->denies('create-contact')) {
    abort(403);
}

Gate::resource('photos', 'App\Policies\PhotoPolicy');

Gate::define('photos.view', 'App\Policies\PhotoPolicy@view');
Gate::define('photos.create', 'App\Policies\PhotoPolicy@create');
Gate::define('photos.update', 'App\Policies\PhotoPolicy@update');
Gate::define('photos.delete', 'App\Policies\PhotoPolicy@delete');

Route::get('people/create', function () {
    // Create person...
})->middleware('can:create-person');

Route::get('people/{person}/edit', function () {
    // Edit a person...
})->middleware('can:edit,person');

Route::post('people', function () {
    // Create a person...
})->middleware('can:create,App\Person');

// From this:
public function edit(Contact $contact)
{
    if (Gate::cannot('update-contact', $contact)) {
        abort(403);
    }

    return view('contacts.edit', ['contact' => $contact]);
}

// To this:
public function edit(Contact $contact)
{
    $this->authorize('update-contact', $contact);

    return view('contacts.edit', ['contact' => $contact]);
}

$this->authorizeForUser($user, 'update-contact', $contact);

...
class ContactsController extends Controller
{
    public function __construct()
    {
        // This call does everything you see in the methods below.
        // If you put this here, you can remove all authorize
        // calls in the individual resource methods here.
        $this->authorizeResource(Contact::class);
    }

    public function index()
    {
        $this->authorize('view', Contact::class);
    }

    public function create()
    {
        $this->authorize('create', Contact::class);
    }

    public function store(Request $request)
    {
        $this->authorize('create', Contact::class);
    }

    public function show(Contact $contact)
    {
        $this->authorize('view', $contact);
    }

    public function edit(Contact $contact)
    {
        $this->authorize('update', $contact);
    }

    public function update(Request $request, Contact $contact)
    {
        $this->authorize('update', $contact);
    }

    public function destroy(Contact $contact)
    {
        $this->authorize('delete', $contact);
    }
}

$user = User::find(1);

if ($user->can('create-contact')) {
    // do something
}

<nav>
    <a href="/">Home</a>
    @can('edit-contact', $contact)
        <a href="{{ route('contacts.edit', [$contact->id]) }}">Edit This Contact</a>
    @endcan
</nav>

<h1>{{ $contact->name }}</h1>
@cannot('edit-contact', $contact)
    LOCKED
@endcannot

Gate::before(function ($user, $ability) {
    if ($user->isOwner()) {
        return true;
    }
});

php artisan make:policy ContactPolicy

class AuthServiceProvider extends ServiceProvider
{
    protected $policies = [
        Contact::class => ContactPolicy::class,
    ];

<?php

namespace App\Policies;

class ContactPolicy
{
    public function update($user, $contact)
    {
        return $user->id == $contact->user_id;
    }
}

...
class ContactPolicy
{
    public function createAny($user)
    {
        return $user->canCreateContacts();
    }

// Gate
if (Gate::denies('update', $contact)) {
    abort(403);
}

// Gate if you don't have an explicit instance
if (! Gate::check('create', Contact::class)) {
    abort(403);
}

// User
if ($user->can('update', $contact)) {
    // Do stuff
}

// Blade
@can('update', $contact)
    <!-- show stuff -->
@endcan

if (policy($contact)->update($user, $contact)) {
    // Do stuff
}

public function before($user, $ability)
{
    if ($user->isAdmin()) {
        return true;
    }
}

Testing

Application tests often need to perform a particular behavior on behalf of a particular user. We therefore need to be able to authenticate as a user in application tests, and we need to test authorization rules and authentication routes.

Of course, it’s possible to write an application test that manually visits the login page and then fills out the form and submits it, but that’s not necessary. Instead, the simplest option is to use the ->be() method to simulate being logged in as a user. Take a look at Example 9-24.

public function test_it_creates_a_new_contact()
{
    $user = factory(User::class)->create();
    $this->be($user);

    $this->post('contacts', [
        'email' => 'my@email.com'
    ]);

    $this->assertDatabaseHas('contacts', [
        'email' => 'my@email.com',
        'user_id' => $user->id,
    ]);
}

You can also use, and chain, the actingAs() method instead of be(), if you prefer how it reads:

public function test_it_creates_a_new_contact()
{
    $user = factory(User::class)->create();

    $this->actingAs($user)->post('contacts', [
        'email' => 'my@email.com'
    ]);

    $this->assertDatabaseHas('contacts', [
        'email' => 'my@email.com',
        'user_id' => $user->id,
    ]);
}

We can also test authorization like in Example 9-25.

public function test_non_admins_cant_create_users()
{
    $user = factory(User::class)->create([
        'admin' => false
    ]);
    $this->be($user);

    $this->post('users', ['email' => 'my@email.com']);

    $this->assertDatabaseMissing('users', [
        'email' => 'my@email.com'
    ]);
}

Or we can test for a 403 response like in Example 9-26.

public function test_non_admins_cant_create_users()
{
    $user = factory(User::class)->create([
        'admin' => false
    ]);
    $this->be($user);

    $response = $this->post('users', ['email' => 'my@email.com']);

    $response->assertStatus(403);
}

We need to test that our authentication (sign up and sign in) routes work too, as illustrated in Example 9-27.

public function test_users_can_register()
{
    $this->post('register', [
        'name' => 'Sal Leibowitz',
        'email' => 'sal@leibs.net',
        'password' => 'abcdefg123',
        'password_confirmation' => 'abcdefg123',
    ]);

    $this->assertDatabaseHas('users', [
        'name' => 'Sal Leibowitz',
        'email' => 'sal@leibs.net',
    ]);
}

public function test_users_can_log_in()
{
    $user = factory(User::class)->create([
        'password' => Hash::make('abcdefg123')
    ]);

    $this->post('login', [
        'email' => $user->email,
        'password' => 'abcdefg123',
    ]);

    $this->assertTrue(auth()->check());
    $this->assertTrue($user->is(auth()->user()));
}

You could also use the integration test features to direct the test to “click” your authentication fields and “submit” the fields to test the entire flow. We’ll talk about that more in Chapter 12.

TL;DR

Between the default User model, the create_users_table migration, the auth controllers, and the auth scaffold, Laravel comes with a full user authentication system out of the box. The RegisterController handles user registration, the LoginController handles user authentication, and the ResetPasswordController and the ForgotPasswordController handle password resets. Each has certain properties and methods that can be used to override some of the default behavior.

The Auth facade and the auth() global helper provide access to the current user (auth()->user()) and makes it easy to check whether a user is logged in (auth()->check() and auth()->guest()).

Laravel also has an authorization system built in that allows you to define specific abilities (create-contact, visit-secret-page) or define policies for user interaction with entire models.

You can check for authorization with the Gate facade, the ->can() and ->cannot() methods on the User class, the @can and @cannot directives in Blade, the ->authorize() methods on the controller, or the can middleware.