If you find my content useful and want to support the channel, consider contributing a coffee ☕: https://hbyt.us/coffee

SvelteKit is a framework for building modern, high-performance, browser-based applications. It was developed by the team behind the popular Svelte framework and is powered by Svelte. Unlike other JavaScript frameworks, it doesn't use a virtual DOM or deliver a bloated and slow application.  

In this SvelteKit tutorial, I demonstrate how to protect routes in your SvelteKit application using the handle hook.

⭐ Starting Code
https://github.com/huntabyte/sveltekit-protected-routes

📁 Final Code
https://github.com/huntabyte/sveltekit-protected-routes/tree/final-code

💽 Check out my other SvelteKit Videos!
https://youtube.com/playlist?list=PLq30BP0TIcqXP149TyFMfRhnMT6T5--e5

📚 Resources Mentioned In This Video:
SvelteKit: https://kit.svelte.dev

🚀 Become a channel member: https://hbyt.us/join
💬 Discord: https://hbyt.us/discord
🐦 Twitter: https://hbyt.us/twitter
🖥️ Setup Stuff: https://hbyt.us/gear

📃 Topics Covered:
- How to add authentication to SvelteKit
- How to protect routes in SvelteKit
- Hooks in SvelteKit
- SvelteKit Middleware
- SvelteKit Protected Routes
- Handle hook SvelteKit
- How do hooks work in SvelteKit?
- What does the handle hook do in SvelteKit?
- Auth Guard in SvelteKit
- How to guard routes in SvelteKit
- What is SvelteKit?
- How to authenticate users in SvelteKit


__________________________________________

(Affiliate links may be included in this description. If you choose to purchase a product from one of those links, I may receive a small commission at no cost to you. Thank you for supporting the channel!)

In today's video, we're going to learn about the handle hook in SvelteKit, and we're also going

to learn how to apply that handle hook to protect routes across our application.

This has been a highly requested topic, so I'm really looking forward to the video.

If you learned something today, I would greatly appreciate a like and subscribe.

And without further ado, let's go ahead and get into the video.

So we're going to start off with a diagram that I prepared here just to kind of help visualize the handle hook, what it's doing, where it's place is in all of this.

And we're going to start over here on the left with the client.

So a client makes a request to the server, right?

Well, the hook is gonna receive every single request to the server.

So it hits the hook first, before it ever hits your page.servers, your layout.servers, before anything is ever rendered to the client, it has to pass through this hook.

And I like to break the hook down into 3 different stages here.

And I think this helps to kind of visualize what is going on.

So the first stage here, I know it says 2, but that's the step in the process.

The first stage here within the hook is as the request hits the server and before the response is generated.

So before the response that we're going to send back to the client is generated.

And before we do anything else within our load functions, within our actions, within our server endpoints, this stage occurs.

So we have access to that request event within this stage here.

We can set the locals, which we will talk about later on.

I know that's kind of a hot topic and people are pretty confused by what locals is, but we will talk about that, I promise.

We can check authentication status before moving forward.

There's a lot of different things that we can do here in this piece, right?

We can also manipulate the request as well.

We can set cookies to it, whatever we want to do here.

And then what's going to happen next is once we're done with all

of this and we say await resolve event, what this is

going to do is actually going to render the route and generate the response.

And to do so, let's just say that in our scenario here, we are requesting data from page.server.ts over here, right?

As, as you would expect, if you just made the request without the handle hook except this event that is passing here To all of these different functions depending on where you're headed to if you're heading to a server It's going to get passed into the request handler if you're heading to the page.server or layout.server it's going to be passed through that load function.

And that's, that's always what we're destructuring out of these different load functions here.

So we pass that updated event and we say, Hey, here's the updated request event.

They do things with this, with this request, right?

They either take action based on it and they can also change the response.

So we're able to set cookies inside of form actions and things like that, as well as load functions if you really wanted to.

So they're able to manipulate the response, they receive the request, they're able to do things with the response.

They send the response back to the handle hook.

They say, okay, I'm done, here's the response.

And all this is happening while we're awaiting for this event to resolve.

Now we can also assign this to a variable, right?

We can assign this value here to a variable and say, const response equals await resolve event.

So then instead of our handle hook, we now have access to that final response, which is ready to be sent to the client, but we can also manipulate that even further.

So we can say response headers and set some custom headers Anything else you wanted to do with that response at the end of every request before it goes back to the client We can do so in our handle hook.

I hope this makes sense to you all we're gonna look at some code examples too, which might clear

clarify if you're less of a visual learner and you have to actually see the code itself to fully understand it.

that we have this baseline covered, let's move into some code and look at some real life examples.

And I've prepared like a little bare bones application that just kind

of simulates some of the common use cases for working with hooks and some things you might want

to do with them such as authentication checks, protecting routes, and so on and so forth.

So the application itself is not super complex.

the description below, but really that's not the focus.

I want to focus on what we're actually doing inside of the hook.

Okay, so this is what a hook looks like if you don't define 1 at all.

So even if I didn't have this file here, this is essentially what is happening.

we can do is we can take this hook here and

we can just say const response equals await resolve event.

This will help us visualize our little 3 step process that I was mentioning earlier.

And then after we have the response would be stage 3.

So if we pull up our diagram here, let me zoom in a bit so you can see it.

So we have this first stage of the handle hook here, which is the blue box that occurs here.

We also have stage 2, which is the purple box that's happening as this is awaiting to be resolved.

And then we have this last stage, the third stage here, which is after the response is generated, where we can take action on this response object.

Now it's yelling at me right now because I haven't returned a response, but we'll say return response down here.

It's going to auto format, but I hope this helps to kind of clarify where these certain things take place.

Because that is an important piece of this.

So 1 thing I want to start off with is event dot locals.

I often hear that and I'm, I guess it would make sense that someone might think that that is local storage, but it's not locals is literally just a custom object that gets built when your request comes through your handle hook.

And then it's passed along with the request event to the rest of your server sides, fel kit functions, your load functions, your actions, and

And then when that request leaves, locals is no longer there.

The next request comes through, creates locals again.

Again, it's all based on what you have defined here.

So just to kind of demonstrate this, what I can do is

And TypeScript is going to yell at me because I do not have a type defined for this.

If you are using TypeScript, You can just define your types here in the interface locals within your app namespace, but, but since I'm going to have both JavaScript and TypeScript users watching this, I'm not going to spend too much time on type safety in this video.

So we have event.locals.something, and I'm setting it to equal to whatever I want.

Now this event.locals.something will be available in all of my other server-side load functions and actions.

So I can go into my routes here, my page.server.ts, and please again ignore this login route here.

This is just to simulate logging in for the next part of this lesson.

But inside this load function, what we can do is we can take in locals.

And you'll see down here at the bottom in my console, I have something, whatever I want, right?

We also have access to it within the actions themselves.

So if I do want to log in here, and let's just say that I need access to something that I have stored in locals to properly handle the login for whatever reason, right?

So now when I click this login button, we'll see that we have, I saved the page, so it reloaded, but then I also hit the action, right?

It also redirected me to the homepage, which triggered this load function to run again, which also const log locals.

So you can think of locals as an arbitrary object or a custom object that you can pass between the handle hook and the rest of the server side Svelte kit functions within your application.

And a more practical use case for this would be something like authentication.

I know that I've, I do this pretty often in my other videos, pocket base and super base.

And I think that's where I've heard concerns about storing user in local storage, but that's not actually what's happening.

So I have a basic auth simulation function set up here.

Again, just imagine this is your client, your database client, your Sulu based client, whatever you're deciding to use to authenticate your users.

And it's either going to return the user of different types here.

So I have admin users and regular users, or it's gonna return null if the user doesn't exist and it's, it's getting this information from a cookie, but again, that's not really super important, but let's just say that on every single request in my application, I want access to the user.

I want to know who is logged in, if anybody at all.

Well, what I can do here is I can say event.locals.user equals validate or I'm sorry, authenticate user, which is my own custom function.

And it's going to take in the whole event.

Really the only thing I actually need from this is the cookies, but I just decided to pass the whole event to not add extra complexity here.

So now it's setting event.locals.user, right?

As every request hits our application, hits our server, it's going to set Event.locals.user to whatever the value of this is, right?

And we can see that it can return either a user or null.

If it's null, then obviously we don't have a user.

If it's 1 of the users, then we have a user.

So we can access that information to properly render data for specific users, take action on behalf of specific users.

So if we look here at the console, we have this user being console log, right?

Because we are still console logging that user inside of page that server.ts.

So we have access to the authenticated user on every request to our server.

So I'm going to get rid of this console log for now.

I'm not going to really do anything with this at the moment, but let's just say that I want to have some protected routes and I want to protect this protected route here.

So what I can do is I can take in locals here and I can check, I can say, if not locals that user, then I

So you can't access this protected route here.

And if I open up my browser dev tools here and we look at our network tab, I'm sorry, we look at our application tab.

And we're going to go to the protected route.

So we can see here that I'm now in the admin panel.

Now, what if I go back home and I log out?

Now you can see that I no longer have a cookie.

Okay, I'm clicking on it, but nothing's happening.

And if I console log here and say access denied, just to show that this is in fact what's triggering that.

When I click on this, you'll see in my server console here, we're getting access denied.

Now you may be wondering about nested routes, right?

So this item down here, this 1 doesn't have a page.server, right?

And let's try to go to slash protected slash item.

So that means we have to create another page dot server, do the same thing on every single route.

You can do that, but there's better ways to handle this.

And again, it's really going to depend on your application and what parts you want to be protected and which parts you don't want to be protected.

to be very broad and just say, we're going to have a slash protected, which could be your slash dashboard, your slash admin, your slash whatever, and let's learn how we can utilize hooks to properly protect this route here.

So we'll have none, nothing here on this page dot server.

So now if I'm logged out, I can access this admin panel again.

And what we can do is we can actually access the request.

So if we look here at the Svelte kit documentation on this, they, they're showing a similar example here where they're just intercepting the request and returning a new response, but we're going to be doing something different.

But if we click on this request event, we're going to see everything that we have access to from that event.

So we have cookies, which we were using to authenticate this user.

We have access to locals, which contains custom data that was added to the request within the handle hook, params, platform request, route, route ID.

So I'm not gonna go through everything, but you're gonna be able to get some cool ideas if you check this documentation out.

So what we're gonna do is we're gonna check to see if URL, I'm sorry, if event.url.pathname, all lowercase, dot starts with, and we wanna see what does this path name start with?

If it's in slash dashboard slash admin, then you would put slash dashboard slash admin here.

So everything behind protected, we want to protect.

We don't want to allow any requests to get there ever.

So we can do is we can actually move this above this and have this check here.

And then what we can do is we can say if not event.locals.user.

to the homepage or to the login page if we had 1, wherever you want to redirect those users to.

as I save that page, we are directed to the homepage because I'm not authenticated, I don't have a cookie.

But if I log in, now I have a token, I can now access protected.

And I guess I should probably demonstrate accessing the nested item.

But again, we don't have any protections on our page dot server at

So this is a really, really, really easy way for you to pretty much mass protect an entire directory, just like this.

Now you're still going to want to have access to that user so that you can verify that, you know, the users aren't trying to create items for other users and things like that.

But this is a really nice way to just kind of lump sum.

If they don't have, if they're not authenticated, they can't access any of these routes.

So now let's take it a step further and let's just say that we have another folder inside of protected.

I'm just going to paste this folder here.

So in this case, we only want users with the admin role to

be able to access this page and then all the directories that fall underneath of it.

But everything else is good to be just an authenticated user.

Well, we can come into here and narrow this down.

So they for sure have to be authenticated, right?

So we can leave this alone in here and that'll cover all the protected routes.

But then we can also add an if statement here.

We can say if event.url.pathname.startswith,

Now we can check if event.locals.user.role is not equal to admin.

back to the protected page, for example, right?

It's like, hey, you can't access this page, but you can access this 1.

If you look at my token or my cookie here, I'm logged in as a regular user.

So imagine that I just logged in as a user that has a role in the database as just a regular user, right?

So let me clear this out and let me switch over my auth function here to turn this into an admin user.

Just imagine I'm logging into a user that now has the role of admin.

So now if I try to go to protected routes, you're going to see that it's been, it's blocking me, right?

Let's see if I can access protected slash item.

I can in fact go to protected slash item.

And again, I'm not sure if I showed this or not, but let me log out here.

So this admin page has an extra layer of protection on it.

So let me switch my user back up to a regular user.

Let's log back in, log back in as a regular user.

If I try to go to admin, you can see that I'm not able to get to admin.

I'm being blocked because I don't have the right roles for that.

So this is a really easy way that you can essentially handle route protection at the hook level for entire directories and sub directories of routes.

And again, the nice thing about having this event.locals here, that's passed to our load functions is on the homepage, we can just go to our server load function here and take in locals And we can return user is locals.user.

And now on our page.svel, we can come here and say, welcome.

And we need to open up some script tags at the top and take in page data.

So if data user, we're going to say welcome user dots, welcome data dot user dot email, Because I don't have a name on the user at the moment.

So if I save this now, I go back to my homepage here.

I actually tried to import an environment variable for some reason, but Now you can see we get welcome user at example.com.

And I can also run a check here too, saying, okay, I don't really need this login button here if I'm already logged in.

So else, if you're not a user, you need to log in.

So now when I log out, we now just see the login, right?

Now you definitely probably don't be passing a bunch of sensitive information through that, right?

So make sure you're conscious of what you're passing and what you're sharing around, and it's going to be rendered on the page.

Again, you don't want to overexpose yourself, but just information like the status of a user being authenticated is not so secure that you're going to become compromised.

Additionally, these cookies specifically here are, if we look here, are HTTP only, right?

So they're server side only, same site strict, and

Okay, so that is how you can protect routes with the handle hook.

And again, if we come back to the documentation, you can really start to see a lot of

the different things that we'd be able to do with the various things that we're getting back.

the examples they show here is checking that, if it starts with a certain address, they just return a whole new response.

And if we were to return a new response here, so if we said if event.url.pathname.startswith, let's just say slash dog, It's a return new response, custom response, and we go to localhost slash dog.

We can see here we get custom response rendered on this page.

So We didn't even hit any of our server side code whatsoever beyond the handle hook.

So we can also call multiple handle function with a sequence helper function, which is essentially like middleware.

So we can see here that it's a helper function for sequencing multiple handle calls in a middleware like manner.

So you can see here they import sequence from Svelte.js slash kit slash hooks.

They set a first, it's essentially going to take in an event and resolve just like the handle function does.

They're doing a transform page chunk here, which if you read up in the documentation for hooks, it applies custom transformations to HTML.

So if we notice here inside of the, where was it?

We see they're transforming the page chunk here.

See all Huntabyte transcripts on Youtube

Protect SvelteKit Routes with Hooks