Build a Starter Kit With Inertia and Fortify

Sign in Get started

This episode is for members only

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

Already a member? Sign in to continue

Playing

12. Redirecting to the intended location

Episodes

0%

Your progress

Total: 5h 21m
Played: 0m
Remaining: 5h 21m

Join or sign in to track your progress

01. Setting up

01. Introduction and demo

02. Installing Inertia from scratch

03. Installing Tailwind

04. Layout and navigation

05. Installing Fortify

06. Exposing routes with Ziggy

07. Global modals

02. Authentication

08. Registering users

09. Sharing the authenticated user globally

11. Signing out

12. Redirecting to the intended location

03. Feature management

13. Adding feature management checks

14. Client-side feature management

04. Building a toast feature

15. Basic flash messages with Inertia

16. Building a toast plugin

17. Styling and transitioning the toast

05. Profile management

18. Creating an account layout

19. Detecting and highlighting current pages

20. Updating profile details

21. Profile photo output and swapping

22. Storing a profile photo

23. Changing user passwords

24. Account feature toggling

06. Password confirmation

25. Using a modal for password confirmation

26. Confirming user passwords

07. Two factor authentication

27. Building the two factor modal

28. Showing a QR code

29. Enabling two factor authentication

30. Disabling two factor authentication

31. Showing recovery codes

32. Fixing password confirm redirect

33. Fixing password confirm flow when enabling

34. Challenging the user when signing in

08. Email verification

35. Mail setup and forcing email verification

36. Adding a verification notice

37. Resending the verification email

09. Account recovery

38. Sending a recovery email

39. Setting a new password

10. Fixes and improvements

40. Closing the user navigation on click

Transcript

00:00

So redirecting to the intended location is a really important part of an app. Basically, when we go ahead and click on this dashboard, which we don't have protected with middleware at the moment,

00:09

if we're not authenticated, we want to show the login modal. Then, when we've entered our details in that login modal, we want to be redirected over to the dashboard. Now, we're going to come across an issue with some

00:21

of the middleware we already have defined in our Laravel app in a moment. We're going to change that and fix that up. But then I'm going to show you how this actually works.

00:29

And how it redirects to our intended location. And this is really important. Because later, we're going to want to change around some of the default responses

00:38

that get returned when we're working with Fortify. OK, so let's first of all go over to our dashboard controller and add in the middleware here to protect this. Of course, this needs to be an authenticated user.

00:51

And you can do this at the root level or within the controller. It doesn't matter. So we'll apply our middleware to here. And now, sure enough, when we click on dashboard,

00:59

we should not be allowed in. But what actually happens is we get a root login not defined error. Now, this isn't anything specific to Fortify.

01:08

It's just because over in our web routes, we have called this auth.login. And the default middleware within our project, if we just head over to HTTP middleware and authenticate,

01:21

expects to be redirected over to the root called login, which we don't have. So we're just going to change that over to auth.login. As simple as that, that is now going to work.

01:30

Now, because we've set up our modal functionality with this package which works with roots, what that means now is when we click dashboard, we're going to be forwarded over to auth.login,

01:40

and our modal is going to appear. So everything worked really nicely. Now, when I go ahead and sign in, you'll notice that we will be redirected over

01:50

to our dashboard. So everything is looking good. But what's going on behind the scenes here? How is this actually redirecting us over

01:57

to our intended location? Well, what we're going to do is do a little bit of source diving again. And we're going to go back over to that authenticated session

02:06

controller. And we're going to talk about these responses, which pretty much happen for every action we take within Fortify. Now, these are really clever because these are customizable.

02:17

We can, within the Laravel container, bind different responses based on certain actions. We're going to do that later. But I'm going to go over this now

02:26

so we've got a little bit of an idea of how this works. So we've already kind of looked at the login pipeline when we were diving in to try and find out that remember Boolean that we passed through.

02:37

But this is returning a login response. So what is this login response? Well, let's go ahead and just open this up. We've got a contract, which means

02:45

we can change this over within our container. So we can bind our own response to this if we want to to a class of our own. And this here, this file at the top,

02:56

is the actual login response. So this is part of the Fortify package. So we're not going to modify that directly, of course. But let's take a look.

03:03

So this, when it gets cast to a response, checks if we need JSON, which we don't because we're working with inertia. And otherwise, returns some data about two factor.

03:16

But otherwise, it redirects to the intended location. So this is pretty much what we want. Now, we're actually going to be modifying this response later when we get to flashing messages,

03:26

so when we show our host notification at the top of the page. But let's take a look at this Fortify redirects as well. So if we open up the base Fortify class in here,

03:36

so Fortify source, let's look at redirects. So this basically pulls from config and looks under our redirect section. Now, that might seem a little bit weird

03:46

because if we open up our Fortify config and we search for redirect, this doesn't exist in here. This is something that's kind of opt-in. You can add it yourself.

03:57

So for example, if you wanted to redirect to a specific location with any of the functionality that we have, you can add in that redirect there. And we might be doing that later depending on how we get on.

04:08

But I think it's useful to work out how this kind of stuff is working. So for almost every action that we take when we create a user account, when

04:16

we enable two factor authentication, all of that stuff, we always almost get returned a response in here, which we can directly modify. So later, if we needed to do something slightly

04:27

different after the user is logged in and we needed that response to behave a little bit differently, we can bind a new thing to the container. So we can bind a new class to the container

04:39

and implement our own login response. So that's basically what's happening. But now we've got that issue fixed up. And we know that this prompts the sign in.

04:49

We can go ahead and sign in. And because we've just looked at that login response, we know that this redirects to the intended location, which in this case is the dashboard.

Episode overview

In this episode, we're diving into how to properly handle redirecting users to their intended destination after authentication in a Laravel app. First, we take a look at a common scenario: when someone tries to access a protected route (like the dashboard) without being logged in, they'll be prompted to log in, and after successful authentication, they should end up back where they originally wanted to go.

We start by adding authentication middleware to our dashboard controller to protect it. Right away, we hit a hiccup—an error about a missing login route. It turns out our Laravel setup expects a route named login, but ours is slightly different (auth.login). We quickly adjust this in our middleware, and now clicking "Dashboard" launches the login modal as expected.

After logging in, we see we're correctly redirected to the dashboard. That's great, but then we go a little deeper to figure out how this redirect is actually happening. We take a peek under the hood at the Fortify package, looking at the login response and how it figures out where to send us after login. We also explore how these responses are customizable—meaning if we ever want to change what happens after login (like showing a flash message at the top), it's totally possible by binding our own response classes in Laravel's container.

Throughout, we get a better understanding of Fortify's redirect system, including optional redirect configuration in the Fortify config file, and the flexibility we have to tweak things later if our app needs custom behavior.

By the end, you'll know why redirects work the way they do after authentication in Laravel, how to fix common routing issues, and where to look if you need to customize the authentication flow in your app.

Episode discussion

No comments, yet. Be the first!