Requests are not secured. Use a UUID instead like so:
When a user signs in, generate the UUID using their email + namespace and see if that matces any user records. If not, store it as a new key - value pair (UUID and email)
For all future calls, we use the UUID, which is impossible to guess without knowing both the namespace (secure UUID on it's own) and the user's email.
Breakdown:
User logs in. We send a request to the server, "Hey! This person logged in with this email. They have a UUID stored?"
The server has to generate the UUID based on the email and the namespace every time.
If the server says, no they don't, we store it in the databse. We then respond to the client with the UUID.
If YES, we're simply generating the UUID, checking for an existing record, if it's there we just return that UUID to the client.
Either way, the process is: ask, generate, check for match, return UUID. There's just an extra step where we save the UUID if there's no match.
Then the client has the UUID. Store it in a HttpOnly cookie for use in subsequent requests. It doesn't really have to expire, but probably should regardless after 30 days or something.
Requests are not secured. Use a UUID instead like so:
When a user signs in, generate the UUID using their email + namespace and see if that matces any user records. If not, store it as a new key - value pair (UUID and email)
For all future calls, we use the UUID, which is impossible to guess without knowing both the namespace (secure UUID on it's own) and the user's email.
Breakdown: User logs in. We send a request to the server, "Hey! This person logged in with this email. They have a UUID stored?"
The server has to generate the UUID based on the email and the namespace every time.
If the server says, no they don't, we store it in the databse. We then respond to the client with the UUID.
If YES, we're simply generating the UUID, checking for an existing record, if it's there we just return that UUID to the client.
Either way, the process is: ask, generate, check for match, return UUID. There's just an extra step where we save the UUID if there's no match.
Then the client has the UUID. Store it in a HttpOnly cookie for use in subsequent requests. It doesn't really have to expire, but probably should regardless after 30 days or something.
https://www.npmjs.com/package/uuid for generating the UUID in the new API routes.