Authentication with Laravel Sanctum and Vue
This episode is for members only

Sign up to access "Authentication with Laravel Sanctum and Vue" right now.

Get started
Already a member? Sign in to continue
Playing
11. Handling authentication errors

Episodes

0%
Your progress
  • Total: 1h 35m
  • Played: 0m
  • Remaining: 1h 35m
Join or sign in to track your progress

Transcript

00:00
Because we've abstracted away the login process to our useAuthComposable, right here, we're going to need to capture any errors that we get when we try to log in, like any validation errors, or if the user doesn't exist, and then go ahead and show them on the front end.
00:16
So what we're going to do is just at the top, create some more state out, not necessarily state up here, but we're going to hold some errors within a ref directly in here. So our ref is going to be empty at the moment.
00:29
Let's call this errors, keep it simple. And we're going to go ahead and share them errors, of course, so we can output them on the login page or on our home view, as we have it at the moment. Okay.
00:42
So to start with, if we head over to our home view, let's pull these errors in where we are using our composable and let's just dump them on the page somewhere. So let's just put them at the top of this form. Okay.
00:55
So now if we do get any errors here, we want to handle them and set them inside of that ref. And it's up to you, what you do in here. At the moment, I'm just going to go ahead and capture any 4.2.2
01:06
errors, which are validation errors. So we can check the response status code and compare it to 4.2.2. And if that happens, we're going to go ahead and set the value of that ref to the errors that we get back.
01:19
So let's say response data and errors. And then we'll also do here. So we don't progress any further, or at least so we can not progress further is go ahead and return.
01:32
A promise rejection in here with just an empty value. You could even set the errors directly inside of this rejected promise. So then you could read them, but I kind of want these errors to be as part of our state.
01:47
Okay. Now that we've done this, let's try this out. So I'm going to go over. And as you can see, we've already got these pre-filled, but I'm going
01:54
to get rid of these and hit login. And yeah, we're already logged in. Let's go ahead and manually sign ourselves out, get rid of these, hit login, and there we go.
02:03
So we have them errors now as part of our state. Let's just very quickly go ahead and include these as part of our validation errors in our form. And we'll be making this a little bit better later.
02:14
So we'll keep this super simple by now and just create our paragraph, checking if we have an error for our email address, if that's the case, we're just going to say errors and email, and we'll just grab the first one. Cause we could have multiple validation errors.
02:31
We'll do the same thing for our password here. So let's swap this to password. Swap this to password and we should be good. We'll start this up a little bit better later when we get round
02:41
to building out our full system. Okay. So again, I'm just going to go ahead and unauthenticate by clearing them out. And yep, sure enough, our validation errors are working.
02:50
And of course, if I enter my email address, but an incorrect password and hit login, you get the, these credentials do not match our records. Okay. A really simple way to do that, but let me show you how to do this in this
03:03
promise, just in case you want to do it slightly differently and have these errors more local rather than as part of your state, I'm going to revert this afterwards, but at least you'll know how to do this. Okay.
03:14
So what we're going to do is say login action, but then we're going to catch an exception in here. So let's go ahead and catch this exception and console log that exception out. If we try this out in our console and make sure we're unauthenticated and we
03:32
try this with the incorrect password, you can see that it just dumps out null because over in use auth, we rejected this with null, but what we could do is we could just do this with the errors in here. You could even have both if you wanted to.
03:48
And you'll see now that when we type in an incorrect password, we get back all of them errors. What this means is that over in wherever you're using these, you could just take the errors from here and set them maybe locally, so you might have a local errors
04:03
ref inside of here with no errors in by default, and if we get rid of our errors from here, what you could then do is set them errors to the result of here. That needs to be errors.value. So that's going to work in exactly the same way.
04:18
If we just make sure we import ref here and head over, you'll see that again, if we just clear this stuff out, you get exactly the same effect. So it's entirely up to you how you do this. I'm not going to do this.
04:33
So I'm going to get rid of that, but at least you know how to do that if you want to. Okay. Finally, let's go over to use auth and just set this back to null and we should be good. We could also get rid of ref just here.

Episode summary

In this episode, we focus on improving how authentication errors are handled in our app. Since we've got the login logic abstracted into a useAuth composable, we want to make sure any errors (like validation problems or wrong credentials) get captured, stored, and shown to users in a friendly way on the frontend.

You'll see how to create a reactive errors ref to hold any authentication errors, and how to display these errors at the top of your form. We walk through how to capture specific error responses (like status code 422 for validation issues) and update the errors ref accordingly.

We then add logic to show error messages next to the relevant fields—like the email and password—so users know exactly what went wrong. There's also a brief demo of an alternate approach: handling errors more locally in your views instead of keeping them as part of global state, and when you might want to do that.

By the end of the episode, you’ll have a nice, basic workflow for catching and displaying authentication errors—making for a better experience for your users whenever something doesn’t go right at login.

Episode discussion

No comments, yet. Be the first!