refactor(auth): Updated authentication logic

[rajdip-b]

Description

Fixes #76
Fixes #105
Fixes #97

This PR refactors the logic of the following:

• How sign-ups and sign ins are made using email
• How emails are verified

Changes made:

• Signing up with any OAuth platform will set isEmailVerified to true. No verification emails will be sent
• Endpoint for signing up and signing in with email has now been moved to a single endpoint /api/auth/send-verification-email. This logically serves the purpose of creating a user if that doesn't exist and sending the verification code thereafter.
• No changes have been made to any request bodies.
• Minor improvements in code

[adelinaenache]

When sending a post request to /send-verification-email with an existing user email, we're returning too much info.

See this log for example:

Nest] 8563  - 06/19/2024, 11:26:38 PM     LOG [HTTP] POST /api/auth/send-verification-email 201 6.979524ms - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0 ::ffff:127.0.0.1
{
  code: 201,
  exit: '{"id":"clxm9yiiq000012vgsz14npq0","email":"[email protected]","name":null,"profilePictureUrl":null,"authType":"LINKEDIN","isEmailVerified":true,"onboarded":false}',
  endDate: 2024-06-19T20:26:38.580Z

An exit with {ok: true} would be enough

[adelinaenache]

Since we're refactoring, could we return DTO's? Create a User.dto.ts that will be returned when the request should return an user.

[adelinaenache]

I'm not a fan of the long naming of the endpoint auth/send-verification-email. I think that this endpoint's concern is authenticating with email, so auth/email should be enough. Also, this naming would be more in line with other auth endpoint names(auth/facebook, auth/apple, etc)

This one is up to you, so let me know what you think!

[adelinaenache]

Let's add SELECT_USER_PROPS const in user.service.ts and use it whenever we want to send an user in the API. This way, whenever a user property name changes or is added, we don't need to change 1231312 queries.

this.SELECT_USER_PROPS =  {
        id: true,
        email: true,
        name: true,
        profilePictureUrl: true,
        authType: true,
        isEmailVerified: true,
        onboarded: true,
      },

and use it like:

return this.prisma.user.update({
     where: { id: user.id },
     data: { onboarded: true },
     select:this.SELECT_USER_PROPS
   });

[adelinaenache]

Add @BypassOnboardingCheck() to:

• GET auth/social-accounts
• PUT user
• PUT user/profile-picture

[rajdip-b]

When sending a post request to /send-verification-email with an existing user email, we're returning too much info.

See this log for example:

Nest] 8563  - 06/19/2024, 11:26:38 PM     LOG [HTTP] POST /api/auth/send-verification-email 201 6.979524ms - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0 ::ffff:127.0.0.1
{
  code: 201,
  exit: '{"id":"clxm9yiiq000012vgsz14npq0","email":"[email protected]","name":null,"profilePictureUrl":null,"authType":"LINKEDIN","isEmailVerified":true,"onboarded":false}',
  endDate: 2024-06-19T20:26:38.580Z

An exit with {ok: true} would be enough

I think a selective return will do the trick. No worries!

[rajdip-b]

I'm not a fan of the long naming of the endpoint auth/send-verification-email. I think that this endpoint's concern is authenticating with email, so auth/email should be enough. Also, this naming would be more in line with other auth endpoint names(auth/facebook, auth/apple, etc)

This one is up to you, so let me know what you think!

Sounds cool!

[rajdip-b]

Let's add SELECT_USER_PROPS const in user.service.ts and use it whenever we want to send an user in the API. This way, whenever a user property name changes or is added, we don't need to change 1231312 queries.

this.SELECT_USER_PROPS =  {
        id: true,
        email: true,
        name: true,
        profilePictureUrl: true,
        authType: true,
        isEmailVerified: true,
        onboarded: true,
      },

and use it like:

return this.prisma.user.update({
     where: { id: user.id },
     data: { onboarded: true },
     select:this.SELECT_USER_PROPS
   });

Agreed!

[rajdip-b]

Since we're refactoring, could we return DTO's? Create a User.dto.ts that will be returned when the request should return an user.

We can do that!

[rajdip-b]

Add @BypassOnboardingCheck() to:

• GET auth/social-accounts
• PUT user
• PUT user/profile-picture

I think these would be typically used AFTER the user has been onboarded. Do let me know if my understanding is incorrect.

[adelinaenache]

When sending a post request to /send-verification-email with an existing user email, we're returning too much info.
See this log for example:

Nest] 8563  - 06/19/2024, 11:26:38 PM     LOG [HTTP] POST /api/auth/send-verification-email 201 6.979524ms - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0 ::ffff:127.0.0.1
{
  code: 201,
  exit: '{"id":"clxm9yiiq000012vgsz14npq0","email":"[email protected]","name":null,"profilePictureUrl":null,"authType":"LINKEDIN","isEmailVerified":true,"onboarded":false}',
  endDate: 2024-06-19T20:26:38.580Z

An exit with {ok: true} would be enough

I think a selective return will do the trick. No worries!

We don't need any info from this endpoint. Sending anything regarding the user without confirming that the user has access to the account it's a security risk. (Even sending errors if the email is not in db would allow a bad actor to know if someone uses our service our not, which is not horrible but not ideal)

[adelinaenache]

Add @BypassOnboardingCheck() to:

• GET auth/social-accounts
• PUT user
• PUT user/profile-picture

I think these would be typically used AFTER the user has been onboarded. Do let me know if my understanding is incorrect.

These are used in the onboarding process, before the user has finished the onboarding.