In this episode, we're tackling a tricky issue around password confirmation redirects, especially when fetching sensitive info like recovery codes that are behind a password-confirm middleware. Basically, the problem happens when a user hasn't recently confirmed their password: we want to prompt them for it, but the default redirect logic doesn't play nicely when our request is triggered by things like Axios, rather than a normal page navigation.
We start by exploring how the middleware is set up and intentionally reduce the confirmation timeout to 10 seconds so we can quickly test the flow. When we try fetching the recovery codes, we see the expected error about password confirmation being required. Then we catch that specific error and automatically trigger our password confirmation modal. However, after confirming the password, we're redirected awkwardly back to the homepage (which is not what we want for modals).
Digging into the underlying Fortify response, we see it uses the 'intended' redirect—perfect for normal page flows, but not for our use case. To resolve this, we override the password confirmed response so that if no intended location exists (like with our modal), we simply redirect back to the current page. This gives us a much smoother experience: after confirming the password in the modal, we stay in context instead of being booted elsewhere.
To round it out, we tweak our modal behavior so it always closes when confirmation is successful, regardless of the redirect. We add a toast notification to make the flow clearer to users, especially since there isn’t really an actual redirect happening after an Axios request confirms their password.
Finally, we test everything to make sure the fix works for both modal/AJAX workflows and standard page navigation, then revert the timeout to something more reasonable. Overall, in this episode, you'll learn how to handle these edge cases when combining password confirmation, modals, and API requests!