I don't know about you all, but I'm a for protecting large groups of routes in the handle Hook.
@benaloney2 жыл бұрын
Is that a custom Svelte emoji in a KZbin comment???! 🤯🤯🤯
@Huntabyte2 жыл бұрын
@@benaloney one of the perks of being a channel member
@swyxTV2 жыл бұрын
:simp:
@krazymeanie2 жыл бұрын
@@swyxTV 😭
@theether59932 жыл бұрын
Me too btw great tutorial
@richardfeynman-sd3rg2 жыл бұрын
This is high quality stuff, the kind of errors most people would make and gloss over. Hoping now that sveltekit 1.0 is out, it starts to get some serious industry traction.
@maskman48212 жыл бұрын
Wow, I really learned a lot from your tutorials about Sveltekit, this is the best and the most valuable learning resources for people who want to quickly dive in Sveltekit application development, I have actually got stuck in authentication for quiet a while because I have no idea how hooks, locals, etc. work and what do they do until your tutorials come out and it save my day, thank you so much 🙏🙏🙏
@Huntabyte2 жыл бұрын
Thank you so much!
@boian-inavov2 жыл бұрын
Thanks for bringing exposure to this! Since the layout call is cached on continuous redirections it shouldn’t actually be used for auth, but hooks should be, since they’re running on every request as middleware. Still it seems like an easy mistake to be made, so people should definitely be mindful of this case 👏
@Huntabyte2 жыл бұрын
You’re welcome! Exactly, or check every page.server load and action.
@jrmc732 Жыл бұрын
thb this is a framework issue (I know the Developer needs to know this), but this mistake is too easy to make, a framework should protect you from doing extremly dumb things.
@RedBlade32 жыл бұрын
Wow this was awesome! Thank you so much for this! Hopefully you'll do more security / structuring videos! I'll try to support you financially next year because these vids are so valuable for me! Keep it up
@Huntabyte2 жыл бұрын
Do not worry about supporting me financially! Just viewing my content and providing feedback is more than enough support!
@thothtrismegistus9292 жыл бұрын
@@Huntabyte I could only find updated videos on your channel. Can you also do a video on implementing sveltekit auth with directus?
@Huntabyte2 жыл бұрын
@@thothtrismegistus929 this has been highly requested and is certainly something on my radar to work on very soon!
@adamshand Жыл бұрын
I was making this mistake and being confused by why it wasn't working as I expected. Thanks!!
@Huntabyte Жыл бұрын
You're welcome!
@codewithguillaume2 жыл бұрын
Dude gonna watch this as soon I am at home
@codewithguillaume2 жыл бұрын
As a svelte user I feel that it’s very interesting
@チョリパン-j4f Жыл бұрын
Thank you so much, I was doing exactly the example of the beginning
@somebodyHereFor5 ай бұрын
MAN, IDK HOW TO THANK YOU ENOUGH
@Hugos682 жыл бұрын
Thanks for covering this in a video
@Huntabyte2 жыл бұрын
You’re very welcome!
@_phenomen2 жыл бұрын
Supabase's SvelteKit starter guide is a security disaster
@lukatoseus Жыл бұрын
Is that still the case?
@MatiasMeno Жыл бұрын
@@lukatoseusno. It uses a combination of hooks, locals and depends to make sure your routes are invalidated.
@DevTesting-lw6ed11 ай бұрын
I had to read the whole github issue comments to understand the supabase implementation.
@lwinklly10 ай бұрын
This video appeared in my recommended loads of times over the past year and I never clicked it, I only remembered now it because I just found out our site has this problem lel
@SumanthChinthagunta2 жыл бұрын
I was using login check wrongly in layout , thanks for explaining
@DavePerth2 жыл бұрын
Thanks Hunter - letting you know the github links are broken, but you can find them in all Repositories...
@Huntabyte2 жыл бұрын
Whoops! The repo was private!
@samifouad Жыл бұрын
it's not necessary to make another request just to validate a user, it works but for latency reasons it's easier to work with JWT in an http only cookie as they can be a tool to quickly validate the request as authentic without an extra network request to do the same work
@Huntabyte Жыл бұрын
There are a few different trade-offs with JWTs vs Sessions.
@MikeHTMLAllTheThings Жыл бұрын
Great insight, totally didn't consider this.
@whatever7338 Жыл бұрын
The problem is that you shouldnt be running these checks on the client anyway.
@Huntabyte2 ай бұрын
None of these checks are done on the client in this video :)
@jangxyz7 ай бұрын
1 year later, for some reason cloning the exact same repo#main does not seem to show the behavior. It always runs "Run Layout Auth Check" for the same scenario. Any idea why? Curious as it is running the same sveltekit version (1.0.0)
@FisshatsyonHaileamlak Жыл бұрын
do you think this happens for react router too?
@weistrass Жыл бұрын
Does this apply to server.js API routes?
@Huntabyte Жыл бұрын
Yes!
@7on11 ай бұрын
No, +server api routes do not inherit from +layout.server files.
@mihaiandrei4342 жыл бұрын
Dang. Didn’t knew this. Thank you!
@Huntabyte2 жыл бұрын
You’re welcome!
@sourabh8044 Жыл бұрын
Thanks for another great tutorial. Could you please create a video for firebase and sveltekit authentication?
@swyxTV2 жыл бұрын
did you look at the svelte auth package the vercel guys put out? does that solve things
@CokaKoala2 жыл бұрын
The example project thankfully demonstrates the correct usage by awaiting the parent in the protected +page.ts routes (I had a GitHub link here directing to the +page.ts in the example repo, but KZbin didn’t like that 😂) But with that being said, users are still capable of incorrectly setting up the auth by doing what Hunter demonstrated, even with the provided package. If you validate the session in +layout.ts , but don’t await the parent in the child routes, you’ll face this exact issue
@Huntabyte2 жыл бұрын
Exactly what @Adrian said. The handle wrapper svelteauth provides only sets the session/user into locals, it doesn’t actually protect anything - it’s up to the developer to implement that themselves.
@kvetoslavnovak42310 ай бұрын
Trying to have the check in root layout.server.js but this causes infinite loop redirect for me 😞 It seems there is no way in SvelteKit to solve this.
@rafaelrocha39915 ай бұрын
there is, use server side hook checks 🙂
@tensor5113 Жыл бұрын
If you're doing resource access/manipulation without any user checks and it lives close to the client(not a vpc) you're already introducing a lot of security issues into your app. Always make sure the user has permission, for example, what happens if the organization downgrades their access, the idea of a wildcard param thats actually queryable so close to the client will introduce security issues, be it sveltekit, or any framework. Because your basically saying, I'm trusting this small niche feature of a new webapp to always perform as expected through each update
@ricardoamendoeira3800 Жыл бұрын
The main issue here is the server returning data without making any security checks, that's the main issue to be addressed. The server should never return non-public data without checking for a valid token or session. Get that done and all this client side validation becomes purely a UX improvement, as it should be, because you can't force attackers to go through your client side code before making requests to your server.
@Huntabyte Жыл бұрын
I have no clue what you're talking about in your comments as there is 0 client-side validation in this video.
@karolus__2 жыл бұрын
nice vid, what about throwing errors from hooks.server? Are we able to display +error.svelte page?
@Huntabyte2 жыл бұрын
I actually don’t think I’ve had a reason to try that! Let me know if it works for you!
@karolus__2 жыл бұрын
Throwing an error in hooks.server displays default SvelteKit error, I wasn’t able to display error.svelte. The reason is actually simple for example instead of redirecting to login you would like to show 401, 403 or even 404. I guess you can always use page.server to do that, but then your auth logic is splitted a bit
@IBakeCookies Жыл бұрын
What if you copy +layout.server.ts, create +layout.ts and paste the same logic there? Wouldnt that solve the issue?
@--Arthur2 жыл бұрын
I authenticate and authorize every request using `event.locals` - so even if an user somehow navigates to admin routes, they won't see any data. From my POV authorizing users in `layout.server.ts` in more of an accessibility feature to deny navigating somewhere in the first place.
@1roOt2 жыл бұрын
I thought about this as well. Then I thought: What would happen if I somehow disable/intercept redirects in my browser? Is the redirect the only thing protecting the route? Has anyone info about that?
@Huntabyte2 жыл бұрын
I actually haven’t. You could also throw an error to render out an error page in place!
@TimeoutMegagameplays2 жыл бұрын
The redirect is being returned _instead_ of the actual page or usual response. If your browser decides not redirect to the page it's simply going to sit on nothing as no other data has been return from that GET request.
@SRG-Learn-Code2 жыл бұрын
Cool! One odd/wrong question. How would you "protect" some roots in a static page? I know it's impossible to run auth on a CDN or make code not accesible if you know the url but... Knowing the code will be shown, what would you do to make harder the discoverability of new routes. Before anyone ask, yep, I know it's worthless, just wondering.
@otockian Жыл бұрын
The real problem here is that the database call isn't passing the auth token along before it pulls data so that the backend ensures your authenticated and have access to the data. That's the real issue, in fact even with the fixes you did, someone could still spoof and call that call to get customers and still get them. Fix that, and everything you showed here is fixed, and then yes you can do the rest of the stuff. But all backend calls for any sensitive data that should be scoped to a role, should pass that data along.
@Huntabyte Жыл бұрын
No they couldn’t. The hook is pulling/“validating” the token in this example and went you run await parent it makes a request to the server, thus validating the token/session/whatever.
@PanosPitsi Жыл бұрын
@@Huntabytestill if it’s really sensitive data don’t just expose it in an api with no validation whatsoever, client side validation is not for security it’s for user convenience. Never trust the client no matter what, all security implementations should be server side.
@yt-sh7 ай бұрын
TLDR Protected requests happens anyway when using Layout... edit: unless using await parent() where parent layout checks auth or you could use handle hook
@hufuhufu Жыл бұрын
What browser are you using there?
@Huntabyte Жыл бұрын
Microsoft Edge
@hufuhufu Жыл бұрын
@@Huntabyte Cool, thanks. I like those side tabs, looks compact, never knew Edge had that kind of feature.
@maskman48212 жыл бұрын
Sir, can you make a tutorial on Sveltekit + Mongodb CRUD/Auth and page/server route protection, I got reading mongodb data working, but I cant find answers about how to create models and perform Create/Update/Delete operations, hopefully you can help people who want to migrate MERN app into Sveltekit 🙏
@Huntabyte2 жыл бұрын
I will certainly look into this, thanks a ton for the suggestion!
@FlygOnLiTe2 жыл бұрын
High value as always!!
@Huntabyte2 жыл бұрын
Thank you!
@lahcencodery2 жыл бұрын
Thanks for this video, was making this mistake
@Huntabyte2 жыл бұрын
You’re very welcome!
@WooSup111Ай бұрын
Looking this video end of 2024. Seems like the issue is fixed already. without await parent() load function doesn't proceed
@sco1369 Жыл бұрын
Doesn't this assume that the API is insecure in the first place? I should never be able to access sensitive info without providing my JWT (or whatever mechanism you use). In your example, I could access all your data either way because you API exposes it.
@Huntabyte Жыл бұрын
The API is an example. Pretend the API is a direct connection to a DB and the SvelteKit server is acting as our Authorization/authentication server
@ricardoamendoeira3800 Жыл бұрын
@@HuntabyteThe server shouldn't return any data without a valid session or token, all this client side validation is just for user experience, it adds 0 security.
@Huntabyte Жыл бұрын
@@ricardoamendoeira3800 it’s not client side validation. It’s validation in the server load function.
@7on11 ай бұрын
@@Huntabyte Then your example will fail with a 403 because the token being sent to the server is A) invalid or B) deleted. With Pocketbase, it will invalidate the previous session with a logout. So even asynchronous it will fail because PB's auth checks are synchronous. And if you're implementing something by hand with a mysql socket connection or similar, you should really do the same - e.g. pass a token to a request and verify the token is still good before returning the data.
@cloudfumes7367 Жыл бұрын
Surreldb with sveltekit tutorial..
@Lukehagar2 жыл бұрын
I'm in this video, and I don't like it :D
@Huntabyte2 жыл бұрын
😂
@flogginga_dead_horse4022 Жыл бұрын
great video
@Huntabyte Жыл бұрын
Glad you enjoyed it
@Hugos682 жыл бұрын
Hahahaha nice :)
@ROX2 Жыл бұрын
SvelteKit route system is absolutely trashed at this moment. here is critical need one file route system with support of custom route guard\middlewares like it implemented in Laravel or Ember as example.
@PanosPitsi Жыл бұрын
Never compare sveltekit with php again
@kvetoslavnovak423 Жыл бұрын
Thank you very much for this video and explanation of this issue. Do you think the official Supabase GitHub documentation and examples for SvelteKit auth-helpers supabase/auth-helpers/tree/main/packages/sveltekit is incorrect as well?