Feature/auth

[Dan-Y-Ko]

Description

Setup authentication utilizing server actions and http only cookies. Not storing any tokens on the frontend. Auth state is persisted on refresh through calling an endpoint in the backend to check if user can access it (which means they're authenticated).

Added max-age on nextjs cookie to same value as one sent from api.

Added middleware to redirect unauthenticated user if they try to access a protected route. Currently only setup my voyage pages as protected routes because I'm not sure how we want to handle the other routes yet.

Added vercel build script to deploy to vercel only when pushed to dev/staging/main. This is so we don't have tons of unnecessary deployments when pushing to feature branches.

Did husky setup from scratch again, hopefully it works this time. Added a build step to husky. Since we are not deploying to vercel on feature branches anymore, that means the build script isn't being run but it's crucial to run this every time so instead it'll be executed locally.

Issue link

Fixes # (issue)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

I tested through localhost and deployed url.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
chingu-dashboard	⬜️ Ignored (Inspect)	Visit Preview		Jan 13, 2024 0:08am

[JaneMoroz]

@Dan-Y-Ko
In app/(main)/user/action.ts serverSignIn: cookie is this [ 'message', 'Login Success' ], and that's not a cookie (or jwt token). We don't have a jwt token in the response body. We have it in res.headers so I extracted it by doing this:

const cookie = res.headers.getSetCookie();

cookies().set({
  name: "access_token",
  value: `${cookie[0].split("; ")[0].split("access_token=")[1]}`,
  httpOnly: true,
  path: "/",
  secure: true,
});

Need to extract Expires too. And maybe there's a more elegant way to get access_token from the header.

Maybe it would be more convenient to get jwt token from the res body. idk

I can get this cookie in my directoryService so I think everything is working great, but still need /api/v1/teams/{teamId} to be protected route to finish directory-functionality.

[Dan-Y-Ko]

@Dan-Y-Ko In app/(main)/user/action.ts serverSignIn: cookie is this [ 'message', 'Login Success' ], and that's not a cookie (or jwt token). We don't have a jwt token in the response body. We have it in res.headers so I extracted it by doing this:

const cookie = res.headers.getSetCookie();

cookies().set({
  name: "access_token",
  value: `${cookie[0].split("; ")[0].split("access_token=")[1]}`,
  httpOnly: true,
  path: "/",
  secure: true,
});

Need to extract Expires too. And maybe there's a more elegant way to get access_token from the header.

Maybe it would be more convenient to get jwt token from the res body. idk

I can get this cookie in my directoryService so I think everything is working great, but still need /api/v1/teams/{teamId} to be protected route to finish directory-functionality.

This is probably better. We want to get the cookie from the headers. I can't remember why I didn't do that in the first place. As for expiry, ideally we'd want that too.

One thing I didn't implement is route redirection if the user types in the url unauthenticated, but this theoretically should be pretty simple to do. We can disable the links client side in the UI but we'll have to take care of url redirection too.

[JaneMoroz]

This is probably better. We want to get the cookie from the headers. I can't remember why I didn't do that in the first place. As for expiry, ideally we'd want that too.

Expiry is important, we probably need to write some logic for checking if a token is expired.

One thing I didn't implement is route redirection if the user types in the url unauthenticated, but this theoretically should be pretty simple to do. We can disable the links client side in the UI but we'll have to take care of url redirection too.

I think we can do it.