Sign-In Controller

[00:00:00]
>> Speaker 1: Let's go ahead and make the Sign In functionality It's very similar to Sign Up in terms of implementation

[00:00:00]
What we want to do is in our controller, we're going to make another method called log in We'll say Explorer Con log in

[00:00:00]
It's going to be async It's a handler or controller, so it will take a request and a response We can add the TypeScript types

[00:00:00]
We're going to try to catch this What we want to do is get the email from the body Then we want to first find any user in the database who has this email, since emails are unique, so there can only ever be one user with this email

[00:00:00]
There are a couple ways you can do this You can do db.select and pass in from the users table You can also do db.query users find first

[00:00:00]
I'll use the find first method Inside the find first method, we can use the eq function from Drizzle ORM, which is short for equals

[00:00:00]
We want to find the first user where the user's email field equals the email that was passed up If you use find first, you don't need to destructure because it always returns the one thing or nothing

[00:00:00]
If there is no user, you could handle this in different ways If this was a server-rendered app, you could redirect them back to Sign In or Sign Up

[00:00:00]
You could send an error code that the frontend will interpret However, it's generally not recommended to explicitly confirm whether an email exists, as this could be a potential security vulnerability

[00:00:00]
Someone trying to steal an identity could use such a message to confirm an account's existence Most products take an approach of saying "invalid credentials" without specifying whether the email or password was incorrect

[00:00:00]
This prevents potential attackers from gathering information about existing accounts If we have a user, the next step is to compare passwords

[00:00:00]
We'll create a helper function to use bcrypt's compare method This approach allows for easier testing and maintains a single source of logic for password comparison

[00:00:00]
We'll compare the provided plain text password with the user's hashed password If the password is invalid, we need to consider two scenarios: either the user entered the wrong password, or it could be a potential brute force attack

[00:00:00]
In a more robust implementation, you might implement login attempt tracking to prevent repeated incorrect attempts

[00:00:00]
If the password is valid, we'll generate a token using the user's ID, email, and username When sending the user data back, it's crucial to create a new object that doesn't include the hashed password to prevent sending sensitive information

[00:00:00]
For error handling, most errors in this flow would be considered server errors (500 status), such as database query failures, password comparison issues, or token generation problems

[00:00:00]
We'll also add input validation using Zod to ensure an email and password are provided, with optional additional validation for email format and password complexity

[00:00:00]
The implementation demonstrates a secure approach to user authentication, focusing on preventing information leakage and protecting against potential security vulnerabilities.