Fixing password confirm redirect: Build a Starter Kit With Inertia and Fortify

00:05

which means that if the user hasn't recently confirmed their password, this will actually error. Now, we saw that earlier when we made a direct request to show the modal, but we actually

00:15

have an issue with the redirection of this. And let's go ahead and trigger that now and see how we can fix it. So the first thing I'm going to do

00:22

is head over to our Fortify routes within the Fortify package itself. And just down here, we've got this two-factor middleware, which is applied to all of our two-factor routes.

00:32

And as you can see, we've got password confirm as one of them. Now, we want to go ahead and change around the password confirmation timing for this.

00:41

So we want to basically take down the amount of time it takes for this to work. So let's go over to our kernel just to remind ourselves this is called require password.

00:51

We're going to go ahead and pull require password into here. And then we're going to say using. We'll set null for the redirect. And then we'll set, say, 10 seconds for the timeout.

01:02

So that means that a user has to re-enter their password every 10 seconds. So that's enough for us to test this out. So if I click Show Recovery Codes now,

01:10

you can see nothing happens. If we open up our console, we get exactly the same issue as we saw before where we are getting back this message password confirmation required.

01:19

So we've got to go through the same steps now to handle this. If we come over to our two-factor form, that is not too much trouble. We've already done this.

01:27

We're going to go ahead and catch an error in here, compare the status code, and then automatically trigger our modal. So we'll go ahead and say if e response and status is 423,

01:41

then we want to use our router to make a get request, or we could say replace or whatever, to our password confirm modal. So that will be enough just to trigger the modal.

01:52

Now, if we go ahead and try this, sure enough, when I click on this, it will now prompt us to confirm our password. But watch what happens when I enter my password

02:02

and hit Continue. We are redirected back over to the home page. Now, the reason this doesn't quite work is because of the intended redirect from the response

02:11

we get back when we have that confirmed password response in Fortify. Let's dig into that now and actually see what's happening behind the scenes.

02:20

So if we open up our root list again, let's look at our password confirmation. This is the confirmable password controller. So let's go ahead and open that up.

02:29

And you can see here that once we do everything and everything's all good, we get this password confirmed response. So let's open up the actual implementation of this.

02:40

And you can see that this redirects us to the intended location. Now, the intended location is going to be where we want to be at.

02:48

That worked when we implemented this for our dashboard because we clicked to intend to go to the dashboard. But it's not going to work for this reason because we are manually triggering

02:59

this using a root again. This doesn't set the intended location. So we need to figure out how to get this working. And we're going to need to modify this response.

03:09

But what we will do is we will go and copy this over first of all. So I'm going to copy this entire thing. And we'll do just exactly what we've done before

03:17

with our custom responses. And let's put this in here and say password confirmed response. And let's paste that in.

03:27

And of course, change over the namespace now to app HTTP responses. And then of course, we can head over to our Fortify service provider and just switch this over.

03:38

So let's do exactly what we did before up here when we were attaching these to the container. And this is the, let's just check the name, password confirmed response.

03:48

And then this is going to be the concrete implementation of our password confirmed response. So there's a couple of things that we could do here. We could return back.

03:58

But that's not helpful because we kind of want when a user performs an action to go through to that place that they have intended to be. So let's just make sure that we are within our own password

04:09

confirmed response here. And let's look at changing this. So I'm going to change this to back just to demonstrate that this does work.

04:17

And then we'll come up with a better solution. So let's go over to security, hit show recovery codes, enter our password, hit continue. And you can see that technically now we're returned back.

04:27

Now we've returned back to our confirmation modal, which is not really what we want. The user's then going to have to close it off and then click to do what they want to do.

04:36

So that works, but it's not the best solution. So what we could do instead is we could redirect the intended location. But we could swap out what happens

04:45

if we don't have an intended location. So what would we want to redirect back to if we don't have an intended location, like what we're doing with our click

04:55

to trigger our list of recovery codes? Well, what we could do is just say stay on the same page, so kind of like redirecting back. So how do we do this?

05:05

Well, we can actually go ahead and use the route facade here. So let's pull this out. And we could grab the current route, and then we could grab the current route URI.

05:15

So that will basically, if we don't have an intended location, it will just stay on the same page. That's kind of what we want.

05:21

So let's try this out. We've got that 10-second delay, remember, between confirming our password. So that's asked us.

05:28

And if we click Continue, you can see that we stay on the same page. Now that's good, because now if we were to apply the same functionality to our dashboard,

05:35

we wouldn't see it stay on the same page. It would go to the intended location. So for example, if we go over to our web routes up to our dashboard, and we add in that middleware

05:45

to confirm our password, let's just confirm the name, password.confirm, that is still going to work as we intend. So if I click on dashboard, let's just wait 10 seconds and actually use that middleware with the delay.

06:01

So let's say require password using null. And let's just set that to 10 seconds. And let's try this out. So that's asking for our password.

06:16

But because we've not removed the intended, that is now going to go through to the dashboard. So it's working everywhere else, which is good. That's what we want.

06:24

But we're landing on the same page if we don't have an intended location, if we're triggering this manually. So with all that done, let's go back over to our two-factor

06:34

form and look at how we can actually close the modal once we are redirected back when we don't have an intended location. So I'm going to click on this, enter my password,

06:45

and click Continue. It's at this point now that for this specific use case, we want to just close the modal off and land back on this page. So how do we do this?

06:55

Well, we can go and for our password confirm modal, when we send this request through, we always want to close the modal. So that means if we're redirected

07:07

to the intended location, the modal will close anyway. But if we stay on the same page, we want to close the modal. So we're going to create out here a onSuccess callback. And we could extract this out to a function.

07:20

But we're then going to close the modal. Now, where does this close function come from? We don't have it in here at the moment. Well, if we just remind ourselves,

07:27

when we built our modal, we pulled in the useModal composable from Momentum modal, the package we're using. And we have this close trigger. So we can actually close this off directly inside of here.

07:38

So we don't need redirect. We don't need show. We can just go ahead and close this. So now, when the password confirmation was successful,

07:46

close the modal regardless of whether we're redirecting or not. So let's try this whole flow out now then. So let's go and go back over to our security section,

07:56

hit Show Recovery Codes. Now we can enter our password, press Continue. That closes the modal. Now we have confirmed our password.

08:05

Now, the flow of this isn't ideal because the intended location is an Axios request. We can't really redirect to an Axios request. It doesn't really work like that.

08:15

But we can go ahead and click this and enter our password and click it. Now, the reason that happened is because we have that 10-second delay.

08:22

But in reality, your user would then have would have confirmed their password and everything would be good. Now, to kind of get around this issue of this flow,

08:31

what we can do, now that we have modified the response for our password confirmed, we could use a TOAST here. So I'm going to get rid of this JSON response

08:41

because, again, we don't really need that. And we can say, with TOAST password confirmed, please continue, or whatever you want to say, just so it's clear that you can continue the action

08:56

that you are about to take. So let's click Show Recovery Codes, enter my password. And now it's a little bit clearer that I can then go ahead and access what I need to access.

09:07

So you can tweak this depending on how your app is going to work. But I think that's a good solution for closing that model off, redirecting back

09:16

to the same page if we don't have an intended location, if it's something like an Axios request, and then, of course, just being confirmed. Now, I'm going to go ahead and get rid of this from the roots

09:27

in Fortify because having a 10-second delay is not ideal. So we're going to change this back over to password.confirm. So let's switch that back over. And we are pretty much done with that fixed up time.

Sign up to access "Build a Starter Kit With Inertia and Fortify" right now.

Episodes

Transcript

Episode summary

Episode discussion