We would need a view to display a password confirmation form, right? So there needs to be some page where you type in your password to confirm it. And then finally, when you submit that form, you need to validate the password they provide, and redirect where they intended to go. And that's the general shape here. Alright, so we'll look at the tests in just a minute, but real quick, for a visual, let's go into Breeze's auth routes. If we scroll down, yeah, it already includes the necessary functionality to make this work. Okay, so let's just use an example here, even the dashboard is fine. It's not practical at all, but that's fine, just as a demo.

Okay, so let's just use an example here, even the dashboard is fine. It's not practical at all, but that's fine, just as a demo. To access this route, you have to reconfirm your password. Okay, so have a look at your HTTP Kernel. If we scroll down here to the bottom, yeah, so here's a route-specific middleware with a key called password-confirm. This is a require-password middleware. And real quick, if you just want to take a look, if we need to confirm the password, we'll talk about that in a minute, then redirect to the password.confirm route. Alright, and we just saw that a minute ago, didn't we?

we'll talk about that in a minute, then redirect to the password.confirm route. Alright, and we just saw that a minute ago, didn't we? password.confirm, where is it? Yeah. So if we need to confirm a user's password, and I'm going to show you what that logic looks like, if we do, then let's hit this route that will load a confirmable password controller. Okay, so we're going to take a look at this in a minute, but real quick, let's just try it out, password.confirm, and that's all we have to do here. So if I switch over to Safari, I'm already signed in, but if I visit my dashboard, it's

it out, password.confirm, and that's all we have to do here. So if I switch over to Safari, I'm already signed in, but if I visit my dashboard, it's now going to redirect me here. Please confirm your password. I provide it, and now we can see the dashboard. And even better, if I go back to the home page, and I try to access the dashboard again, it's not going to make me enter my password again. That gets stored in the session for, by default, three hours. Okay, so maybe, even if just for learning purposes, you want to figure out, well how would I implement this myself?

Okay, so maybe, even if just for learning purposes, you want to figure out, well how would I implement this myself? Let's use the test to guide us. So we're going to start with password confirmation test, and there's only two or three here to get us started. That should be enough. Test to confirm that the password screen can be rendered. And again, this follows the given, when, then shape. So given, we have a User. When you sign in the User, and you visit the confirm password endpoint, then we should

So given, we have a User. When you sign in the User, and you visit the confirmPassword endpoint, then we should have a response of 200. So this test simply ensures that when you access this route as a signed in User, you get a 200 response. And if we, for example, if we come on down, where is it, right here. If we commented that out, and we give that test a run, of course, it's going to fail. Okay, so that's a simple, easy test to write to get yourself going. Next, test passwordCanBeConfirmed. So once again, given we have a User, when we sign that User in, and we don't submit

And that too should work. Okay, so let's take a break here, excuse me, let's take a break here, and figure out what exactly happens when we hit this endpoint. So we'll start by going to routes/auth, and we have an endpoint set up here that goes to ConfirmablePasswordController. So this controller is responsible for showing that view to confirm your password, and then also handling the submission of that form. So the view, pretty simple stuff, you have an auth card, then you have an HTML form here, you enter your password, and then it submits a POST request to that endpoint. Cool, that's really easy stuff.

you enter your password, and then it submits a POST request to that endpoint. Cool, that's really easy stuff. So if we now come on back, when you submit the form, this is where you go. Submit the request, if it fails, throw a ValidationException, where you basically redirect back to that form, and you display the errors. And we should see that. Errors, and there it is. Display the errors. Okay. But if validation passes, and we'll talk about that more in just a second, then notice redirect

Okay. But if validation passes, and we'll talk about that more in just a second, then notice redirect()->intended. You may not be familiar with this. So Laravel offers these facilities, or whatever the correct term would be. Redirect Guest and Redirect Intended. And these are intended to be used together. Redirect Guest will flash a URL to the session, and then Redirect Intended will pull that from the session and then redirect you there. And it ends up reading fairly well.

from the session and then redirect you there. And it ends up reading fairly well. So if you think about it, if we are accessing an account page that requires password confirmation, well, you click on the dashboard, but it doesn't take you to the dashboard. It takes you to that Confirm Password view. Well, after we handle that view, we still need some way to say, okay, now redirect to where the user intended to go, which is the dashboard. So that all gets stored and saved in the session. Now if you're curious, where do we call RedirectGuest, I'm pretty sure that gets handled in the middleware.

Now if you're curious, where do we call RedirectGuest, I'm pretty sure that gets handled in the middleware. So let's have a look. PasswordConfirm, there we go. Come on down, hmm, there it is. So if we should confirm the user's password, then RedirectGuest. So this is just kind of a fancy way, again, to say RedirectGuest, if you were to use the facade or the helper functions here. So again, basically this redirects to this page, which is the password.confirmation page. putting the actual URL they intended to visit in the session.

So again, basically this redirects to this page, which is the password.confirmation page, putting the actual URL they intended to visit in the session. Have a look. Let's go to an implementation here, and there you go. In this case, it gets the full URL, and it sets that as where you intended to go. So that's where we are flashing that to the session. So if we now switch back to our controller, after you submit the form, let's now redirect you where you intended to go. Okay, so last for this method, have a look here. Auth::validate.

Okay, so last for this method, have a look here. Auth::validate. So you might be used to seeing things like request()->validate. Well, this is a little bit different. You're not validating the request specifically. So we're not doing things like this. We are validating the authentication or the User. And effectively, what's going to happen here is we will fetch the User matching these credentials. So try to find a User with that email and with that password. And if you couldn't find one, then we have an issue where you throw an exception, you

It's really not very complicated at all. Here's the final piece of the puzzle. How do you figure out when it's time to require that the user reconfirms their password? Because again, no matter how many times I refresh here, it won't redirect me to that page. It'll only do it after about, at the time of this recording, maybe 2 hours and 55 more minutes. Let's figure out how that logic works. Okay, well once again, that sort of thing can be handled within your middleware. And that's where this comes into play. Should we confirm the user's password? Let's figure out what Laravel does here.

Should we confirm the user's password? Let's figure out what Laravel does here. It gets the current time, and then it looks into the user's session, and it tries to find something called auth.password.confirmDat. Now if it doesn't find anything, it just defaults to 0. And then it subtracts to figure out how long that period has been. And if that period is greater than the current password timeout, which is 3 hours, 10,800 seconds, divided by minutes in an hour, and then seconds in a minute, yeah, it's 3 hours. So if that span is greater than 3 hours, we need you to confirm your password again. And that is the only condition where we redirect you there.

Then on the next request, even if you refresh the page right there, on the next request, we're still going to hit this. So for example, if I say, die, hello, you're going to hit that for every single request. And if we want to die and see what is confirmed at, 794, 96, it's just going to keep running that check. And eventually, confirmedDat is going to be greater than 10,800. And when it is, yep, it's time to reconfirm your password. And that's the extent of this entire feature. So now, entirely for learning purposes, let's see if we can implement a feature just like this ourselves from scratch.

So now, entirely for learning purposes, let's see if we can implement a feature just like this ourselves from scratch.