DEV-4 - setup supabase and user authentication

[chenxin-yan]

Jira issue

📌 What’s Changed

• revert import alias back to using tsconfig.json as it seems like next.js cannot pick up import alias specified in package.json, leading to cannot find module error.
  • See move absolute path config from tsconfig.json to pacakge.json #1
• remove linter's --fix flag by lint-staged.
  • See Add husky and lint-staged for adding git pre-commit hooks #2
  • See remove pnpm format in pre-commit hook #6
• add .env.example to showcase expected environmental variables
• setup supabase middleare & utility functions in /utils/supabase
• add signInWithGoolge and signOut actions
• add Google Button component
• add auth page and callback route
• add unauthrized page to be redirected to when user's email is not in allowed email domain list
• setup supabase database functions and triggers

✅ Actions Needed

• ✅ It might be a limitation of using OAuth with supabase. We cannot get user email before they registered. As a result, when recognizing a non nyu user, the account information would still be stored in database.
  • We would need to delete the account in database every time a non nyu user logged in. I wonder if there is a more elegant way of doing this.
• ✅ I am not sure how environmental variables should be handled when using devcontainer. I listed all the expected variables in .env.example and they should be set in .env.local. @safipatel you might need to take a look at it.

🔗 Links

• Supabase: Login with Google
• Supabase: Setting up Server-Side Auth for Next.js

[safipatel]

Re: environment variables -> the example env file is good and good catch to consider .devcontainers but it seems like its fine . Next.js is the one reading them in, so as long as people make the file in the repository it should read them in even if its a container.

I do have to put these environment variables into Kubernetes, so that might take a second to figure out before I merge this in.

[safipatel]

RE: @chenxin-yan Oauth out of organization, looks like you can create a trigger in Supabase to avoid it. Not too sure about how this works but it seems these got it to work:
https://stackoverflow.com/questions/73318325/limiting-sign-in-with-google-to-google-workspace-previously-g-suite-users
https://stackoverflow.com/questions/71591949/restrict-supabase-sign-up-to-a-specific-domain
https://www.reddit.com/r/Supabase/comments/1hk5t8q/google_signin_restricted_to_an_org/
https://www.reddit.com/r/Supabase/comments/17ixv3w/comment/l18oe3i/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

This seems like a pretty common problem, so I think one of these or someone else should have gotten this to work.

[chenxin-yan]

@safipatel I will take a look. It seems we can achieve this through a Supabase function and trigger. However, I am wondering if we can pass arguments to the function instead of hardcoding the allowed domains in the Supabase function.

[chenxin-yan]

@safipatel I configured supabase function and trigger, it should be working now. I deleted code that handles domain check as it is handled on database side now. I stored allowed domains in database rather than as env variables so database functions can have access to that infromation.

[safipatel]

Another FYI:
On deployment, we kept getting redirected back to localhost:3000 because of this
https://github.com/orgs/supabase/discussions/26483#discussioncomment-9495394

So we have to add the redirect to the allowed list, also see this: https://supabase.com/docs/guides/auth/redirect-urls