Configurable Authentication for Leaderboard

[UdaySagar-Git]

• [ ] Authentication using NextAuth with various providers (Google and GitHub for now).
• [ ] Login page or a modal pop-up for login.
• [ ] Enable or disable authentication feature.
• [ ] Configurable providers.
• [ ] Role-based configurable routes.

[UdaySagar-Git]

@rithviknishad can you please assign this to me !

[rithviknishad]

This may be an opt-in feature. To be disabled by default and would be disabled for this org's deployment too.

How would you validate a user is allowed to access the deployment?

[UdaySagar-Git]

How would you validate a user is allowed to access the deployment?

• The feature will be disabled by default, and all routes related to authentication (/api/auth) will redirect to the home page if it's disabled.
• The user needs to manually change a flag like (ENABLE_AUTHENTICATION=true) in the environment variables to enable authentication.
• If a user has enabled this flag, they need to provide a client ID and secret from their own OAuth.

[rithviknishad]

Let's say an organization A that has private repositories and their leaderboard is set to include those information, how would you validate if a person is from org. A?

[UdaySagar-Git]

That might be a bit tricky!

• One thing we can do is domain specific validation (email@organization.com).
• Only the users present in the data repository will be validated or allowed.
• We can add something like a request for access, which creates a PR similar to what we have for updating profiles. If and only if the pr gets merged, then the user will get access.

[dgparmar14]

I have one suggestion, Instead of implementing register/login functionality, let's consider adding a toggle on the homepage to switch between private and public repositories. When a visitor toggles to view private repositories, we'll then validate whether the visitor is allowed access. It is less complicated i guess.

[UdaySagar-Git]

@rithviknishad , can we have a separate endpoint that is only accessible to the owner? The owner's email will be placed in the env , and the user with that email can access a route where the owner can add users' emails to allow them access to the website. I think we can somehow have write access permissions for the data repository directly using GitHub's new fine-grained PAT and update the data repository using Octokit. , Also, we can directly update a specific file, such as allowedUsers, from the web using Octokit.

[UdaySagar-Git]

@dgparmar14 we need authentication to verify the users who will have access to private repositories, right? The problem here is how we're going to allow which users will have access to private repositories Let me know if you have any ideas on how this can be achieved