yes I have! I could have used a more brief video that focused on the issue at hand, but credit where it is due for bringing an important consideration to our attention. Thank you.
I was doing data recovery on server actions. but I saw a video on youtube of a senior doing it on the server component. I'm still waiting for your response. I have 2 questions. 1. If the data recovery function needs it in 2 components, can I put it in another file, should it be .ts or .tsx? 2. Definitely the recovery functions would only be in server compent? no exception? to refactor my code. and I have 2 requests. 1. you can make a video about unstable_cache. I saw a video but I don't know what's special about it, I think it's for tag a prisma or a SQL query. since it does not have the tag or revalidate property as in "fetch". 2. You could talk about the react query. Is the caching only on the client side? I mean this doesn't apply to subsequent users who visit the page? Or is the cache only saved by the user who is visiting the application?. 3. The authentication validation, if it is a valid or logged in user, just put it in Middleware or should I put it in both places in the actions and Middleware? How did you say that you have to treat them as public APIs? Or do I just put it in Middleware? thanks
This video is pretty disingenuous. The title should be, "You're exposing data by not authenticating API routes". It has literally nothing to do with Next.js or Server Actions. Any API route created using any technology would be "leaking" data in the same way if the route is unauthenticated. Advertising a workshop 2 minutes in is also hilarious. Will you be teaching prospective engineers about this massive risk in Next.js? Perhaps you should instead be teaching them good data management theory. Rather than blaming parts of the technology for this engineering failure why not teach them to think about data holistically. 1. What data in this route is sensitive? 2. Should the data be limited by some attribute of the user? 3. If not, are we simply providing too much data on this route? In your example, you are exposing all your products... which would be exposed on your site anyways. There is no data leak, in fact, the route created would be a viable one for resellers to utilize in order to pull a real time product list and so could serve additional use cases. I also completely disagree with the idea that engineers should not make exports out of server actions if they aren't immediately planning on re-using them. Functions should be reusable, this is how we build good scalable code. If the code isn't reusable, the real question is why? If it's an authentication issue, then that's an authentication failure not an "exporting something when you shouldn't" failure.
Thanks for your feedback, always appreciate discussions. I completely disagree with you. The reason it has to do with server actions is because devs don’t understand how exporting functions in server actions are in fact creating api endpoints. I agree with you that this is just common practice that we should we protecting routes with Auth and my example was there to show you how that’s happening. And I said it in the beginning, I don’t blame Nextjs. I just think people are really confused with server and client component and aren’t truly understanding how they work. Plus if they expose user info in a endpoint, that’s leaking data so maybe I could have used that as a better example but my point was that you need to be careful as this is how it works. I also pointed out that treat server actions as public API endpoints as people are making this mistake. Re: reusable code, yes you use reusable code that way but prematurely exporting functions which don’t get used is just a code smell. You are coupling functions which might make it harder to refactor, if a functions behaviour changes before it’s stable, it can lead to breaking changes. So exporting it when it’s truly done and needed is the right way to do it.
@@kareemlateefyomi8690 The point made in the video is that you essentially expose an endpoint route that is functionally an API endpoint. Yes I know the difference.
Have you made this mistake before?
yes I have! I could have used a more brief video that focused on the issue at hand, but credit where it is due for bringing an important consideration to our attention. Thank you.
@@sunnybwaj hey definitely feedback received :) thanks for watching!
Good content. Makes perfect sense.
Thanks Ken!
I was doing data recovery on server actions. but I saw a video on youtube of a senior doing it on the server component. I'm still waiting for your response. I have 2 questions. 1. If the data recovery function needs it in 2 components, can I put it in another file, should it be .ts or .tsx? 2. Definitely the recovery functions would only be in server compent? no exception? to refactor my code. and I have 2 requests. 1. you can make a video about unstable_cache. I saw a video but I don't know what's special about it, I think it's for tag a prisma or a SQL query. since it does not have the tag or revalidate property as in "fetch". 2. You could talk about the react query. Is the caching only on the client side? I mean this doesn't apply to subsequent users who visit the page? Or is the cache only saved by the user who is visiting the application?. 3. The authentication validation, if it is a valid or logged in user, just put it in Middleware or should I put it in both places in the actions and Middleware? How did you say that you have to treat them as public APIs? Or do I just put it in Middleware? thanks
?????????????
Can you make a dedicated course on next.js
Yup, I am planning to at nextjscourse.dev/ sign up here to the waitlist!
Please do more work on Lucia auth
I have a video on that, did you check that out?
Yeah but i can implement OAuth through Lucia
?
@@Muhammad-yz8yf what did you want to learn through Lucia?
I want to sign in in website through my Google or GitHub account so is it possible in Lucia
This video is pretty disingenuous. The title should be, "You're exposing data by not authenticating API routes". It has literally nothing to do with Next.js or Server Actions. Any API route created using any technology would be "leaking" data in the same way if the route is unauthenticated. Advertising a workshop 2 minutes in is also hilarious. Will you be teaching prospective engineers about this massive risk in Next.js? Perhaps you should instead be teaching them good data management theory. Rather than blaming parts of the technology for this engineering failure why not teach them to think about data holistically.
1. What data in this route is sensitive?
2. Should the data be limited by some attribute of the user?
3. If not, are we simply providing too much data on this route?
In your example, you are exposing all your products... which would be exposed on your site anyways. There is no data leak, in fact, the route created would be a viable one for resellers to utilize in order to pull a real time product list and so could serve additional use cases. I also completely disagree with the idea that engineers should not make exports out of server actions if they aren't immediately planning on re-using them. Functions should be reusable, this is how we build good scalable code. If the code isn't reusable, the real question is why? If it's an authentication issue, then that's an authentication failure not an "exporting something when you shouldn't" failure.
Thanks for your feedback, always appreciate discussions.
I completely disagree with you. The reason it has to do with server actions is because devs don’t understand how exporting functions in server actions are in fact creating api endpoints. I agree with you that this is just common practice that we should we protecting routes with Auth and my example was there to show you how that’s happening. And I said it in the beginning, I don’t blame Nextjs. I just think people are really confused with server and client component and aren’t truly understanding how they work. Plus if they expose user info in a endpoint, that’s leaking data so maybe I could have used that as a better example but my point was that you need to be careful as this is how it works.
I also pointed out that treat server actions as public API endpoints as people are making this mistake.
Re: reusable code, yes you use reusable code that way but prematurely exporting functions which don’t get used is just a code smell. You are coupling functions which might make it harder to refactor, if a functions behaviour changes before it’s stable, it can lead to breaking changes. So exporting it when it’s truly done and needed is the right way to do it.
I hope you know the difference between server actions and api
@@kareemlateefyomi8690 The point made in the video is that you essentially expose an endpoint route that is functionally an API endpoint. Yes I know the difference.