A second and third version of this course released using Next 13+, but this course is great if you want to see another example fullstack project. We now recommend you take the Build an AI-Powered Fullstack Next.js App, v3 course.

Check out a free preview of the full Build a Fullstack App with Next.js, v2 course:
The "Sign In API Route" Lesson is part of the full, Build a Fullstack App with Next.js, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Scott completes the route handler for the signin route. The handler finds the user in the database, compares the saved hashed password with the password submitted from the form, and logs the user in if the password is valid.

Get Unlimited Access Now

Transcript from the "Sign In API Route" Lesson

>> So the strategy for Sign in is a little different. It is a little different. One, we're not creating a user. You shouldn't be creating a user on sign in. So what we're gonna do is we're also gonna check to see if it's a post. Instead of creating a user, we're just gonna check to see if there's even a user.

[00:00:18] With that email that you gave us, is there even a user that has that email if it's not. Are you just barking up the wrong tree just get out of here if there is we're going to compare that user's password that we found with the plaintext password that you sent us on this request if that matches you must be who you say you are because the email returned the user and that hashed password on that user matched your plaintext password so I guess you are that user.

[00:00:47] In that case we'll create a JWT, we'll set the cookie and we'll do the same thing. So let's do that. Export default async function. And I'll just call it signIn. We'll just go ahead and bring in our types from next. Next API request next API response Request or response type those.

[00:01:19] There's also like a next API handler that you can just make, you know, for the whole function and you don't have to do these individual ties but I've liked all that. Okay, if racked up method equals post Then let's see if there's a user here. User equals awaits.

[00:01:41] Bring our DB in, .user .find. Not many find unique Where email is wrecked up by that email.I t's also noted that in a production environment you would probably,verify sanitize You know, pretty much any input that sent to your API, you want to look at that. Make sure it's, you know, it's there.

[00:02:15] I'm just making a ton of assumptions right now in this code. But that's the difference between, you know, building an app and then building an app for production is that there's a lot more that goes into production. You have to verify a lot of these inputs. And things like that because you can't trust what a user sending you even if all the users or the people on your team and it's an internal app you still can't trust it so make sure you verify everything including inputs and have fallbacks for all that stuff and even then you still won't get it, right.

[00:02:43] All right, it's just it's just hard. It's a moving target. Okay, so we got user. So then what we want to do is we just want to compare those passwords so we'll say const is user and we can say a weight compare passwords plaintext password that's going to be wrecked up body that passer.

[00:03:03] That's the one that they sent up from the form and then the hash one is it's got to be user dot password there we go. So if you can say cool if is users true then we can go ahead and To do exactly what we already did, which is creating a JSON Web Token and doing all this magic, so I'm just gonna go ahead and bring those in right quick.

[00:03:33] Don't try to autocomplete them, there we go and there we go. Same thing as the last one, create a JSON web token, set the header called set cookie, serialize the JSON web token in a cookie to a one and good to go. Else if it's not a post, give it a status, whatever you wanna call it, whatever status you wanna do.

[00:04:02] And end it. Any questions on sign in? Yes. These API routes are server less. Correct?
>> Correct? Yes, they are serverless. They run on Versailles infrastructure, which I believe do not quote me on this, but I believe it's Google. I think it's Google, but it doesn't matter. That's.

[00:04:35] that's the whole point. It doesn't matter servers.