Although as a matter of fact, day by day passwords are becoming a major source of security threats in this era, so it's not long before orgs move towards passwordless solutiions.

@@pranavrajveer3767 Nobody disagrees with that, but "not long before" is a key part of your sentence... we are not quite there yet and it is very frustrating how awkward they make it. In current day, people still want password auth.

As a service user I strongly prefer applications where I can login using auth from a trusted provider. Given the number of folks out there interested in home-brewing their own solutions I, as a user, don't really have much trust in those solutions given the number of high profile breaches.

I think it's a good choice by Next auth. For learning purposes, it's good to know how to handle passwords and whatnot but realistically it's best not actually used.

A bcrypt implementation isn't so difficult, but then you need to do the whole boilerplate as well such as forgot-password, set-new-password-after-forgot, send-email-confirmation, resend-email-confirmation, confirm-email, change-password, change-email, confirm-change-email, etc.

Me too, still looking at a blank screen not having a clue. Can't be done without daddy git I guess. This is almost making me want to go back to pounding nails for a living.

Use clerk way easier

@@skyhappy I'm def considering it.

also kinde@@skyhappy

Wow @catchshyam you nailed exactly the topics I was going to ask for! Excellent tutorial Jack. 1) middleware is important so that one does not have to repeat the same get session and redirect code on EVERY protected page (and open up the door for forgetting to do so) 2) getting the access tokens to APIs is a critical piece... it would be great to initialize a wrapper for that external API ONCE (like a singleton) that takes the access_token once, and make it so every page/route etc has the ability to call that API without individually getting the access token (normally a jwt token) and 3) customizing the auth page is also important, and fairly easy to do in the pages router version of Next.js but have yet to try in app router version.

YES

Agreed. You can scope that to either a sub-layout or into the page handler if you want to avoid that.

Good observation. Where would we ideally put it?

@@tinhoCs At the top of the dynamic layout.

@@jherr Thanks for the quick reply Jack. Any way you can paste a short snippet here just so I'm clear?

@@tinhoCs Sorry, no. There is a Discord server associated with this channel and you can request help there. Please READ and FOLLOW the #rules BEFORE posting. And the Next Auth folks have support channels as well.

Thank you!

I wish it was "you guys", it's just me. ;)

@@jherr you're kidding !

Put the check in a shared layout.

Yep That's another very valid strategy for protected routes.

There is a Blue Collar Coder Discord server where you can ask the community for answers to questions like these.

And how to authorise user on database, like JWT (user from string)

Hey! I tried to roll my own back-end with JWT Credentials Auth. As far as I know it's not possible in App Router if you're rolling your own server, because Next.js Server can't set the cookies, only read them. So if you're relying on JWTs, you won't be able to do much, unless you expose your access and refresh tokens from back-end - which you obviously do not want to have. This and other things are to be addressed in NextAuth v5, which is still in development.

The nextAuth is notorious when it comes to custom configuration. Jack help us 🙏

@AmadeusTwi I've managed to set JWT tokens with Next 12. I had troubles with them, but it's possible

@@igogs7095 That is the point. Pages Router (Next.js 12) DOES work. App Router (Next.js 13) - DOESN'T.

No. First of client components SSR. And second client components can have RSCs as children or element props.

That's something we do manually in ScreenFlow to highlight the code I'm talking about.

Client components can take RSCs as children and they are still RSCs. Client components cannot _invoke_ RSCs. But they can take them as children. So you didn't need the middleware. Also, to get the user identity on the client you need the provider.

@@jherr thanks for clearing this up!

Yes. I've done a full month of investigating state management solutions and building a big tutorial for Redux, Zustand, Jotai and React state and the older video was providing anti-patterns. I think I even said in that video that it was super preliminary and I put it out mostly to get the conversation started. After a month of research I now worry that people started to take it as gospel.

@@jherr ok makes sense, i look forward to the big reveal then. thanks for getting back to me 👊

You mean like Clerk or auth0 or something?