Idea for an example (JWT Auth Server)

[gautvm]

I figured creating an example of making a JWT auth server using Prisma might be useful, with access tokens, user storing, sessions, password hashing, isAuth middleware, etc.

The routes would look like this

POST

• /register: Register a user which returns an access token to log in.
  • Body:
    • email: String (required): The email of the user
    • username: String (required): The username of the user registering
    • password: String (required): The password of the user registering
• /login: Log in a user which will return an access token to access protected routes.
  • Body:
    • username: String (required): The username of the user logging in
    • password: String (required): The password of the user logging in
• /logout (protected): Logout a user and delete the session key.

DELETE

• /account/delete (protected): Delete your account

PUT

• /account/update: Update your account
  • Body:
    • email: String (optional): used if the email is being updated
    • username: String (optional): used if the username is being updated
    • password: String (optional): used if the password is being updated

I have a GitHub repo with some of it implemented, though I am going to implement sessions as well.

If this idea gets approved, I will write the example in a way that follows the style of the other examples. I could update this proposed idea in any way that the Prisma team will like it to be.

The data model would look like this

model User {
  id Int @id @default(autoincrement())
  username String @unique
  email String @unique
  password String
  sessionKey String
}

[ruheni]

This is a great idea!

We can go ahead with this.

Before you do, I have a few recommendations. We like to maintain consistency and make them as simple as possible for beginners and experienced developers.

• Borrow inspiration from the other rest-* examples for the structure of the example.
• You can also borrow inspiration from our graphql-auth examples for the extra routes you could add to the example

A general rule of thumb is to test the example to ensure they are working as expected locally before a review. We're working on automating the testing for the *-auth examples.

Once you're done creating the example, add the test in the relevant test .github/test folder. You add a README in the .github./readmes folder and follow our Contributing Guide on generating a README.

Lastly, include the example and the link in the repo's main README file under the relevant section.

If you hit a snag, don't hesitate to let us know. 🙂

[gautvm]

Thanks! Will do.

[IBRAHIMDANS]

Good idea, but I think it's more optimized to have a new model PasswordModel to allow the user to have several login methods. Also i check if new password are used by user
for example:
Users (id, email, passwordId, passwords []) ===> Password(id, userId, isActive, createdAt, updatedAt)

[gautvm]

Good idea, but I think it's more optimized to have a new model PasswordModel to allow the user to have several login methods. Also i check if new password are used by user for example: Users (id, email, passwordId, passwords []) ===> Password(id, userId, isActive, createdAt, updatedAt)

I think it might be better to have an enum like OAuthConnectionType rather than a Password model. Feel free to implement this in the PR, if you'd like (I'll be finishing it up soon).

[XprabhatX]

@gautvm is it implemented yet? Because I saw some tests in pr #2869 are failing (But it's an old pr and this issue is open).