What to expect in the next generation of Laravel Forge. Read the blog post
Rewatch this lesson
Courses
/
Getting Started with Laravel
/
Basic authentication: Registration

Basic authentication: Registration

Getting Started with Laravel

Basic authentication: Registration
Build user registration from scratch to understand authentication fundamentals. Create registration forms, hash passwords, and automatically log in new users.

We're finally going to make use of the Sign In and Sign Up buttons! Well, first the Sign Up button in this lesson.

We've been pretending that we can edit or delete any chirp that's added, and right now, anytime we add a new one, it's just an anonymous person creating this chirp. Time to change that!

Laravel offers complete authentication scaffolding with Laravel Starter Kits, but it's also helpful to know how to manually build it first to understand how things work under the hood. So let's start with user registration and learn what's happening behind the scenes.

Step 1: Create the Registration Form

Let's start by creating a new page. We have our chirps directory where we have our edit page, so it makes sense to create a new directory that is an auth directory. So let's create auth and then we'll have register.blade.php.

Create a new file at resources/views/auth/register.blade.php:

1<x-layout>
2 <x-slot:title>
3 Register
4 </x-slot:title>
5 
6 <div class="hero min-h-[calc(100vh-16rem)]">
7 <div class="hero-content flex-col">
8 <div class="card w-96 bg-base-100">
9 <div class="card-body">
10 <h1 class="text-3xl font-bold text-center mb-6">Create Account</h1>
11 
12 <form method="POST" action="/register">
13 @csrf
14 
15 <!-- Name -->
16 <label class="floating-label mb-6">
17 <input type="text"
18 name="name"
19 placeholder="John Doe"
20 value="{{ old('name') }}"
21 class="input input-bordered @error('name') input-error @enderror"
22 required>
23 <span>Name</span>
24 </label>
25 @error('name')
26 <div class="label -mt-4 mb-2">
27 <span class="label-text-alt text-error">{{ $message }}</span>
28 </div>
29 @enderror
30 
31 <!-- Email -->
32 <label class="floating-label mb-6">
33 <input type="email"
34 name="email"
35 placeholder="[[email protected]](<mailto:[email protected]>)"
36 value="{{ old('email') }}"
37 class="input input-bordered @error('email') input-error @enderror"
38 required>
39 <span>Email</span>
40 </label>
41 @error('email')
42 <div class="label -mt-4 mb-2">
43 <span class="label-text-alt text-error">{{ $message }}</span>
44 </div>
45 @enderror
46 
47 <!-- Password -->
48 <label class="floating-label mb-6">
49 <input type="password"
50 name="password"
51 placeholder="••••••••"
52 class="input input-bordered @error('password') input-error @enderror"
53 required>
54 <span>Password</span>
55 </label>
56 @error('password')
57 <div class="label -mt-4 mb-2">
58 <span class="label-text-alt text-error">{{ $message }}</span>
59 </div>
60 @enderror
61 
62 <!-- Password Confirmation -->
63 <label class="floating-label mb-6">
64 <input type="password"
65 name="password_confirmation"
66 placeholder="••••••••"
67 class="input input-bordered"
68 required>
69 <span>Confirm Password</span>
70 </label>
71 
72 <!-- Submit Button -->
73 <div class="form-control mt-8">
74 <button type="submit" class="btn btn-primary btn-sm w-full">
75 Register
76 </button>
77 </div>
78 </form>
79 
80 <div class="divider">OR</div>
81 <p class="text-center text-sm">
82 Already have an account?
83 <a href="/login" class="link link-primary">Sign in</a>
84 </p>
85 </div>
86 </div>
87 </div>
88 </div>
89</x-layout>

The majority of things we're seeing here are not new. We've seen them throughout our time together. We have a slot where we're saying this is the register page. We're using a layout. We're using a bunch of different forms. We're gathering any errors that we might have. We're showing those error messages, and then we're using old inputs if we have any errors. So again, not much new here!

Step 2: Create the Registration Controller

We could create a new authentication controller, but what we're going to do is kind of split this up into different controllers. We're going to go against the grain just a little bit here.

Laravel recommends using single action controllers (invokable controllers) for actions that don't fit the standard resource pattern. Let's create a dedicated controller for registration:

1php artisan make:controller Auth/Register --invokable

This creates a single action controller in the auth namespace: /Http/Controllers/Auth/Register.php. What this looks like is a single class, an invokable controller, which just means that usually you only have one method per controller. Instead of having a resource controller that has multiple (seven different) methods.

This is really personal preference, but I wanted to show two different ways that you might do it. Everything that we're doing within auth, we're going to have invokable controllers instead of one massive authentication controller that has weird method names.

This creates a single action controller in app/Http/Controllers/Auth/Register.php:

1<?php
2 
3namespace App\Http\Controllers\Auth;
4 
5use App\Http\Controllers\Controller;
6use App\Models\User;
7use Illuminate\Http\Request;
8use Illuminate\Support\Facades\Auth;
9use Illuminate\Support\Facades\Hash;
10 
11class Register extends Controller
12{
13 public function __invoke(Request $request)
14 {
15 // Validate the input
16 $validated = $request->validate([
17 'name' => 'required|string|max:255',
18 'email' => 'required|string|email|max:255|unique:users',
19 'password' => 'required|string|min:8|confirmed',
20 ]);
21 
22 // Create the user
23 $user = User::create([
24 'name' => $validated['name'],
25 'email' => $validated['email'],
26 'password' => Hash::make($validated['password']),
27 ]);
28 
29 // Log them in
30 Auth::login($user);
31 
32 // Redirect to home
33 return redirect('/')->with('success', 'Welcome to Chirper!');
34 }
35}

We just pretend that this __invoke is whatever method we normally would use in our ChirpController, for example. But this is just our register auth controller, and when we call it, it's going to use this invokable function.

Here's what's happening (almost identical to any other method or form that we've done):

  1. Validate the input - We get the name, email, and password. We're making sure the password is confirmed (that's what the password_confirmation field is for).

  2. Create the user - With a hash of that particular password.

  3. Log them in - Using the Auth facade helper method to log in the user we just created.

  4. Redirect - To home with a success status.

It looks like this shouldn't be as easy as it is, right? But it is mostly because of the helper methods that Laravel provides—not just the authentication helper method to log in the user, but also things like Hash to make passwords secure. And because we already have a User model given to us out of the box within Laravel, this becomes incredibly easy to get authentication up and running.

Step 3: Add Routes

Let's add this to our web routes. In routes/web.php, add the registration routes:

1use App\Http\Controllers\Auth\Register;
2 
3// Registration routes
4Route::view('/register', 'auth.register')
5 ->middleware('guest')
6 ->name('register');
7 
8Route::post('/register', Register::class)
9 ->middleware('guest');

There's something I want to add right now. I want to make sure that these routes should be able to be accessed by anyone, even if they're not logged in. This is where middleware comes into play, and Laravel has middleware built out of the box for us. In this case, for the register route, I want to make sure that this is accessible by guests.

I also want to show what a named route looks like. We can pass in a name, and I'm going to call this the register route. We can do the same thing with our POST method as well.

Note: Since we're just showing a view for the GET route, we use Route::view() directly. For the POST route, we pass the invokable controller class.

The guest middleware ensures only non-authenticated users can access these routes. This name helps us—instead of knowing that it is the /register page, maybe we change this to /new for some reason. Well, then we automatically know that it's still under the named route of register.

Step 4: Update the Navigation

We can actually update the navigation instead of that href="/register" to use a named route. But I also want to update this because when we're logged in, we shouldn't show the Sign In and Sign Up page. That's where the @auth directive comes in.

Let's update our layout to show the current user. In resources/views/components/layout.blade.php, update the navbar-end section:

1<div class="navbar-end gap-2">
2 @auth
3 <span class="text-sm">{{ auth()->user()->name }}</span>
4 <form method="POST" action="/logout" class="inline">
5 @csrf
6 <button type="submit" class="btn btn-ghost btn-sm">Logout</button>
7 </form>
8 @else
9 <a href="/login" class="btn btn-ghost btn-sm">Sign In</a>
10 <a href="{{ route('register') }}" class="btn btn-primary btn-sm">Sign Up</a>
11 @endauth
12</div>

Instead of the Sign In and Sign Up buttons, we can say: if someone is authenticated into the application, then we're going to show the authenticated user's name and a logout button (we'll set this up in a bit). Otherwise, let's show the buttons like we had them previously.

Step 5: Protect Routes

So just so we aren't stuck without being able to test, let's go ahead and protect the rest of our routes and update our controllers to use our user now. We can actually group routes with middleware.

Now let's make sure only authenticated users can create chirps. Update your routes:

1Route::get('/', [ChirpController::class, 'index']);
2 
3// Protected routes
4Route::middleware('auth')->group(function () {
5 Route::post('/chirps', [ChirpController::class, 'store']);
6 Route::get('/chirps/{chirp}/edit', [ChirpController::class, 'edit']);
7 Route::put('/chirps/{chirp}', [ChirpController::class, 'update']);
8 Route::delete('/chirps/{chirp}', [ChirpController::class, 'destroy']);
9});

Now everything that we see here is under the auth middleware. So I can't send a new chirp now unless I am authenticated. What does this look like? Well, if I try to send a chirp and I'm not logged in, Laravel gives you something out of the box that—because it knows you're not authenticated—it's going to try to authenticate you by redirecting to the login route.

Step 6: Update ChirpController

Let's go ahead and update our ChirpController because now we're not just creating a new chirp—we're actually creating a new chirp with our users. Now we can use the real authenticated user! Update your controller methods:

1public function store(Request $request)
2{
3 $validated = $request->validate([
4 'message' => 'required|string|max:255',
5 ]);
6 
7 // Use the authenticated user
8 auth()->user()->chirps()->create($validated);
9 
10 return redirect('/')->with('success', 'Your chirp has been posted!');
11}
12 
13public function edit(Chirp $chirp)
14{
15 $this->authorize('update', $chirp);
16 
17 return view('chirps.edit', compact('chirp'));
18}
19 
20public function update(Request $request, Chirp $chirp)
21{
22 $this->authorize('update', $chirp);
23 
24 $validated = $request->validate([
25 'message' => 'required|string|max:255',
26 ]);
27 
28 $chirp->update($validated);
29 
30 return redirect('/')->with('success', 'Chirp updated!');
31}
32 
33public function destroy(Chirp $chirp)
34{
35 $this->authorize('delete', $chirp);
36 
37 $chirp->delete();
38 
39 return redirect('/')->with('success', 'Chirp deleted!');
40}

We're using the auth() helper and we can say that the user of this auth helper, we want to get their chirps, but we want to create them. We can actually create them with that validated parameter.

Since we set up that policy to authorize a user to update a particular chirp, we can add that here. This $this->authorize() method will check if they are authorized to update the chirp, then let's continue. We'll need the controller to have the AuthorizesRequests trait that it can use.

Step 7: Update Chirp Component

Now we still see these edit and delete buttons when we're not logged in, but we've started to authorize if someone is able to edit or delete. How can we only show these edit and delete buttons when we are able to edit and delete them?

Instead of checking if the auth check exists and if the auth ID is equal to the chirp user ID, there's an easier way to do this. We just need to check that policy that we created. Can they update or can they delete a chirp?

Update the chirp component to use proper authentication. In resources/views/components/chirp.blade.php, replace the temporary auth check:

1@can('update', $chirp)
2 <div class="flex gap-1">
3 <a href="/chirps/{{ $chirp->id }}/edit" class="btn btn-ghost btn-xs"> Edit </a>
4 <form method="POST" action="/chirps/{{ $chirp->id }}"> @csrf @method('DELETE') <button
5 type="submit" onclick="return confirm('Are you sure you want to delete this chirp?')"
6 class="btn btn-ghost btn-xs text-error"> Delete </button>
7 </form>
8 </div>
9@endcan

We can use the Blade directive @can to check if they can update the chirp (in this case, the chirp that we're passing in), and then the @endcan directive. In this case, if I can't edit any of these chirps and I can't delete any of them because I'm not logged in, the buttons won't show. But if I sign up and create a new account, after I create a chirp I can actually edit and delete them.

Step 8: Form Protection

While the chirp form is visible to everyone on the home page, the POST route to /chirps is protected by the auth middleware. This means:

  • Guests can see the form but will be redirected to login if they try to submit

  • Only authenticated users can successfully post chirps

  • The middleware protection ensures security even if the form is visible

This approach lets visitors see what they could do if they sign up, encouraging registration.

Understanding Laravel's Auth

Behind the scenes, Laravel:

  • Hashes passwords using bcrypt (never store plain text!)

  • Creates a session when users log in

  • Sets a cookie to remember the session

  • Provides the auth() helper to access the current user

  • Offers middleware to protect routes

Test Your Registration

Let's test this out!

  1. Visit /register

  2. Fill out the form with your name, email, and password

  3. Submit it

  4. You should be logged in and redirected to the home page with a "Welcome to Chirper!" message

  5. Try creating a chirp—it now belongs to you and you can see your avatar!

You now have your user avatar associated with you because you're logged in, and you can see the edit and delete methods available for your own chirps.

What About Email Verification?

Laravel makes email verification easy too! You'd just:

  1. Implement MustVerifyEmail on your User model

  2. Add the verified middleware to protected routes

  3. Laravel handles sending verification emails

We'll skip this for now, but it's there when you need it!

Next Up

Hopefully this shows you that authentication doesn't have to be too scary. Authentication within Laravel is actually incredibly easy because of the tools that it provides. While yes, it's great that you can just grab a starter kit from Laravel and you have authentication out of the box, you don't necessarily need to use it every single time.

That being said, starter kits are great because they have a lot that we're not going to even touch within Chirper, such as password reset pages.

But registration works great, and users need to log back in! In the next lesson, we'll add login and logout functionality to complete our authentication system. Almost there!

00:00
We're finally going to make use of the sign in and sign up button
00:03
first in this lesson, the sign in.
00:05
So we've been pretending that we can, uh, edit or delete any chirp that is added.
00:11
And right now, anytime we add a new one, it's just an anonymous
00:16
person creating this chirp.
00:18
Laravel offers complete authentication scaffolding with Laravel starter kits,
00:22
but it's also helpful to know how to manually build it first, understand
00:26
how things work under the hood.
00:28
So let's start off by creating a new page.
00:30
So we have our chirps directory where we have our edit page, so it makes sense to
00:34
do a new directory that is an off page.
00:37
So why don't we do off and then we'll have a register, blade dot php.
00:42
Lemme paste in this code for us now the majority of things that
00:45
we're seeing here are not new.
00:47
We've seen them throughout our time together.
00:50
We have a slot where we're saying, this is the register page.
00:53
We're using a layout.
00:54
We're using a bunch of different forms.
00:57
We're gathering any errors that we might have.
01:00
We're showing those error messages, and then we're using
01:02
old inputs if we have any errors.
01:05
So again, not much new, but let's see what this looks like.
01:08
Let's go ahead and attach it to our web routes.
01:11
Just to keep things simple.
01:12
For now, let's go ahead and say route view, and this is the slash
01:18
register page, but this is our
01:21
auth register view.
01:23
Now let's go ahead and make sure in our layout, we are actually directing to
01:27
the slash register page and we are not.
01:30
So let's do that slash register.
01:32
Oops slash register in the signup.
01:36
So sign up slash register.
01:38
This is creating a new account.
01:40
Great.
01:41
Everything looks good.
01:41
So we have a name, we have an email and a password, and a
01:45
confirmation of a password.
01:46
Just while I'm here, why don't I make this the slash login route.
01:50
Now we do need to register a user.
01:52
When they complete this form.
01:53
We could create a new, maybe authentication controller, but what
01:59
we're going to do is kind of split this up into different controllers.
02:03
We're going to use PHP Artisan Make Controller,
02:07
and here's where we're going to go against the green just a little bit.
02:11
Instead of saying that this is a auth controller or a register controller
02:16
even, I'm going to say that this is the auth slash register controller.
02:21
And this should be a Invocative controller.
02:24
What this looks like is a single controller created in the auth
02:28
space, so slash http auth, and then register controller.
02:36
And what this looks like is a single class, an invo controller, which
02:41
just means that usually you only have one method per controller.
02:45
Instead of having a resource controller that has multiple, in
02:49
this case, seven different methods.
02:52
So really something like this versus something like this is personal
02:56
preference, but I did want to show two different ways that you might do it.
03:00
So that way everything that we're doing within auth, we're going to
03:03
have invo controllers instead of one massive, uh, authentication controller
03:08
that has weirder method names, because we don't necessarily have an.
03:13
Update method when it comes to authentication, we don't necessarily have
03:16
a show method or an edit method, so this is just a different way of doing this,
03:22
but we just pretend that this invoke is whatever method we normally would use
03:26
in our chirp controller, for example.
03:28
But this is just our register.
03:31
Auth controller, and when we call it, it's going to use this invocative function,
03:36
So almost identical to any other method or form that we've done.
03:40
I'm pasting this in.
03:41
We need to pull in the user model and we're going to pull in the hash support
03:48
facade as well as the auth facade.
03:51
Here's what's happening.
03:52
We're going to validate the input.
03:54
We're going to get the name, the email, the password.
03:56
We're making sure it's confirmed, and that's what that password
03:59
confirmation field that we have is.
04:02
We're going to create the user with a hash of that particular password.
04:08
And then we're going to log in, the user redirecting to the
04:11
home with a status of success.
04:14
Welcome to Charper.
04:15
And that's it.
04:16
It looks like this shouldn't be as easy as it is, right?
04:20
But it is mostly because of the helper methods that Laravel provides.
04:23
Not just the authentication helper method to be able to log in the user
04:27
that we just created, but also things like a hash to make passwords secure.
04:31
And because we already have a user model that's given to us outta the box
04:36
within Laravel, even if we don't have a starter kit that we started with,
04:40
this just becomes incredibly easy to get a register controller or any sort
04:45
of authentication up and running.
04:47
Why don't we add this to our web route?
04:50
So in addition to our view, we're going to add a post route, route
04:54
post of register, and we're going to pass in that register class.
05:00
You can see here that it's grabbing that auth register controller.
05:03
Now there's something I want to add right now.
05:05
Why don't we say that this is the register routes, so that way we know
05:10
and it's easy to see them at a glance.
05:12
But I do want to say that these routes should be able to be accessed by
05:16
anyone, even if they're not logged in.
05:18
This is where middleware comes into play, and Laravel has Middlewares built
05:23
out of the box for us in this case for the register route, I want to make
05:27
sure that this is accessible by guests.
05:30
So we're gonna say this is a middleware of guests, and you can see here that we
05:34
have that middleware available to us.
05:37
And just for fun, I wanna show us what a named route looks like in this case.
05:41
We can pass in a name, and I'm gonna call this the register route.
05:46
And we can do the same thing with our post method as well.
05:49
We're gonna say that this is a middleware of guests.
05:53
And we don't necessarily need to name this because we're just
05:55
posting to the slash register route.
05:58
Using the Register Invo class that we just created.
06:01
This name helps us say, Hey, instead of knowing that it is the slash register
06:06
page, maybe we change this to slash uh, I don't know, new for some reason.
06:12
Well, then we automatically know that it's still under the named route of register.
06:17
We can actually update the navigation instead of this hre
06:21
to register to use a named route.
06:23
For example, instead of that HF of register, I can pass it this route.
06:27
And in here we might be able to see, yes, the register named route.
06:31
And again, the VS.
06:32
Code extension is doing a lot of heavy lifting right here.
06:35
Now I do wanna update this as well, because when we're logged in, we shouldn't
06:38
show the sign in and sign up page.
06:41
Well, that's where the at auth parameter, or the at auth
06:45
directive, I should say, comes in.
06:47
So instead of the sign in and sign up, we can say, okay, well if there is in this
06:53
case, if someone is authenticated into the application, then we're gonna show
06:57
the auth user's name and a logout button.
07:01
We'll set this up in a little bit.
07:02
Otherwise, let's show the buttons like we had them previously.
07:06
What does this look like?
07:07
We have the signup button that still works even with our named route.
07:10
Let's go ahead and sign up Josh.
07:13
Register, welcome to Chi.
07:16
And you can see here that we have my name.
07:18
Log out's not going to work because we haven't created that route just yet.
07:22
So, just so we aren't stuck with this particular user that's logged in, why
07:26
don't we create that logout route?
07:28
We're gonna create a new controller, PHP Artisan Make Controller.
07:33
This is the auth slash logout controller.
07:38
We'll say it's invoke.
07:40
Now in this logout invo controller, it's gonna be the inverse
07:43
of what we did for register.
07:45
We're going to grab the user with the request user.
07:48
Then with the off facade, we're just gonna say, Hey, let's
07:51
log out that particular user.
07:53
We're passing in that user variable, and then we can return a redirect
07:58
with another success message.
07:59
You've successfully logged out.
08:02
Let's add this to our web routes.
08:04
So route post of logout, and again, that's what we're doing in our layout where we
08:09
are creating a form, a method of post to the action of logout, and the CSRF.
08:16
And that's exactly what that button is going to do.
08:19
When we hit that logout button, we are going to call this route post of Logouts
08:26
and that logout class, that Invocative controller that we just created.
08:30
I'm using the middleware of auth, and this is to show that yes, there are
08:34
multiple Middlewares that Laravel gives outta the box, and auth is one of 'em.
08:38
So in this logout option right here, what we're doing is saying, okay,
08:43
only someone who is authenticated can actually hit this logout button.
08:47
Of course, we have that in our layout here with auth as well.
08:53
So now hitting logouts and yeah, we successfully logged out.
08:57
I can't sign back in because we haven't yet implemented that, but
09:00
let's go ahead and protect the rest of our routes and update our
09:04
controllers to use our user now.
09:07
We can actually group routes with middleware.
09:09
What we can do here is route middleware.
09:12
We can say, this is the auth middleware.
09:14
We're going to group everything in this with a function, and we're going to
09:19
say that, Hey, um, within this whole route middleware group, I want to
09:24
grab everything and put this in there.
09:27
Now, uh, everything that we see here is now.
09:32
Under the middleware auth.
09:34
So I can't send a new chirp now unless I am authenticated.
09:39
So what does this look like?
09:40
Well, if I try to send a chirp hi there, and I hit chirp, what
09:43
do you think is going to happen?
09:45
Well, Laravel gives you something out of the box that, because it
09:48
knows you're not authenticated, it's going to try to authenticate you.
09:53
And yeah, we don't have a login route to find, which is the default redirection
09:58
that Laravel gives when you do not have an authenticated user and you
10:02
try to hit a specific, uh, route that uses the auth middleware, that's okay.
10:08
We know it's working.
10:09
Let's go ahead and update our chirp controller, because here now we're
10:12
not just creating a new chirp.
10:13
We are actually creating a new chirp with our users.
10:16
Why don't we do that?
10:17
Within this store method,
10:19
we're going to use the auth helper, and we can say that the user of this
10:23
auth helper, we want to get their chirps, but we want to create them.
10:29
And so we can actually create them with that validated parameter.
10:32
Now my editor is going to give me an error that this method of user is not defined,
10:37
but rest assured, this is correct.
10:40
And then since we set up that policy in order to authorize a user to update a
10:45
particular chirp, we can add that here.
10:47
Now, this authorize, if they are authorized to update the
10:51
chirp, then let's continue.
10:53
And same thing with the edit form as well.
10:56
And then same thing for the Destroy method as well.
10:59
And since we are authorizing a particular user in this update method,
11:03
well, we don't have to say, uh, we want the off users chirp to update
11:08
because we already know that they're able to update this particular chirp.
11:14
Same thing with being able to edit or view that edit page in general.
11:18
Now we still see these edit and delete buttons.
11:20
I am not logged in, but we've started to authorize if someone is able to do this,
11:25
if someone's able to edit or delete.
11:26
Now, if I tried to do this because we have that middleware, I should get an error.
11:31
Yes.
11:32
The route login is not defined.
11:34
But how can we only show these edit and delete buttons when we
11:37
are able to edit and delete this?
11:39
And the chirp blade PHP component for these edit end buttons.
11:43
Let's go ahead and change this.
11:45
We are going to say if the auth check exists in this case, if
11:49
they are authenticated and if the auth ID is equal to chirp user id,
11:55
and actually there's an easier way to do this as well with a blade directive.
11:59
Instead of this, if off check and off ID is equal as it the chirp user id.
12:03
Okay, that's, oh, that's great.
12:06
But really we just need to check that policy that we created.
12:09
Can they update or can they delete a chirp?
12:12
And if they can update it, they can delete it.
12:15
So we can just use this blade directive of can, can they update the chirp
12:22
in this case, the chirp that we're passing in, and then the can directive.
12:27
Oops.
12:27
The end can directive.
12:29
There we go.
12:30
In this case, we cannot edit any of these, uh, and I cannot delete any of
12:35
them because I'm not logged in, but I'm going to sign up, create a new account,
12:38
and show you after I create a chirp that I can actually edit and delete them.
12:44
Sign up Josh two.
12:47
Looks like we have error messages out of the box.
12:50
Good register.
12:52
Perfect.
12:53
My first chirp.
12:56
Chirp, and look it, we have our user avatar associated with
13:01
us because we have logged in
13:02
and I can see the edit and delete methods I can edit and, uh oh.
13:07
Looks like we have an issue here.
13:10
Ah yes.
13:11
Our controller probably has not used the authorization or being
13:15
able to use the authorization trait.
13:17
I don't believe I set that up.
13:19
So let's go to the chirp controller and if we want to use the this authorize,
13:24
what we can do is make sure this controller is set up to authorize.
13:28
Use authorizes requests that pulls in the Use Illuminate Foundation
13:34
Auth Access, authorizes requests Trait for this particular controller.
13:37
Perfect.
13:38
And now that we made that change, now our controller is using that
13:42
authorizes request straight.
13:44
We have the ability to have those authorization policies available so
13:47
we can edit the chirps that we create.
13:50
Edit my first chirp, edited, and update chirp.
13:55
Perfect.
13:56
And we can delete it.
13:57
Your chirp has been deleted.
13:58
Fantastic.
13:59
Hopefully this shows you that authentication doesn't
14:02
have to be too scary.
14:04
Authentication within Laravel is actually incredibly easy because of
14:07
the tools that it provides, and while, yes, it's great, you can just grab
14:11
a starter kit from Laravel and you have authentication out of the box.
14:15
You don't necessarily need to do it every single time.
14:18
That being said, starter kits are great because they have a lot that
14:21
we're not going to even touch within chirp or such as password reset pages.
14:26
But last but not least, why don't we get the ability for users to log in because if
14:30
I log out, I can't sign back in just yet.
14:33
So let's do that in the next lesson.