Generalization for other colleges

[saharsh-agrawal]

One can come up with ways to generalize the use of this platform for other colleges/organizations as well.

[saharsh-agrawal]

Things that are currently IIT KGP specific in the project, and hence will need to change for generalization:

1. Meta (SEO) data
2. paragraphs on certain pages
3. location options
4. single database each for users (which does not store the user's college), trips and trains
5. HEIMDALL for Institute email authentication

[Adi-204]

Thank you for outlining the IIT KGP-specific aspects of the project. After reviewing the codebase and the requirements, here’s my plan to address these changes:

1. Institute Email Authentication (HEIMDALL)
   The first step involves implementing institute email authentication using HEIMDALL. I went through the HEIMDALL documentation and understood that verifying requests involves checking whether the client's IP address matches the public IPs of the IIT Kharagpur network.

However, to test and see the functionalities locally, it seems that requests must originate from within the IIT Kharagpur network, and I would need an IIT KGP email. Could you guide me on how to proceed with this in a testing environment?

2. Tasks Related to Content Changes
   For tasks 1 and 2, updating the website's meta (SEO) data and paragraphs on specific pages can be done directly. These changes are straightforward and mostly involve content updates.

3. Location Options
   For task 3, we have two options:

   1. Manual Update: Extend the data.json file with additional locations manually.
   2. Third-Party API Integration: Use a third-party API to fetch and display location options dynamically. This approach would be more scalable and future-proof.

4. User Database Schema
   For task 4, I propose adding a reference to a new Institution schema within the userSchema. The Institution schema can store institution-related data independently, making the design more modular and adaptable to multiple institutions.

5. Generalizing HEIMDALL Authentication
   As mentioned earlier, I reviewed the HEIMDALL documentation and understand how it checks IP addresses for requests from IIT Kharagpur. Generalizing this process would require modifying the authentication flow to accommodate IP checks or email domains for other institutions.

Please let me know if the proposed solutions align with your expectations and how I can proceed further, particularly with testing the HEIMDALL integration. We can do one task at a time and implement generalization for other Institutes.

[saharsh-agrawal]

I am looking at this in 2 ways:

1. Either we let this repo be a template for anyone from any other college to replicate, modify and host on their own to serve their college.
2. Or we modify the project to work with other colleges as you are suggesting.

Talking about Heimdall:

1. For our case, it simply checks if the email ends with the institute domain and authenticates the user from OTP, and thus similar functions can easily be built for any institute.
2. You can't modify Heimdall directly as it is built only for KGP use. We might need to make a similar authentication system that works for any given college (or use any already existing system for any particular college).

As you can see, we only need to call this auth system once. It authenticates, sets the cookie and is done. Then it is called once again for registering the user to check for validity. That is it, you just need 2 endpoints to any working/new authentication system.

For locations, we might save a list of possible locations for each college, in the same Institution schema.

[Adi-204]

Thank you for the detailed explanation. I understand the two approaches you are considering. Please let me know which direction you’d prefer, or if you have any additional inputs before I proceed.

[saharsh-agrawal]

Let us modulalize the authentication completely seperately in order to achieve the first method, then we can build on it and generalize for other colleges.

[Adi-204]

Draft Solution
Overview
1 Generalize the Authentication Flow:
Replace hardcoded Heimdall URLs with dynamic values read from .env.
2 Introduce an InstitutionSchema:
Store institution-specific details such as name, domain, and locations.
3 Dynamic Redirects:
Use institution-specific URLs for authentication and redirection dynamically based on .env.

Please provide feedback so I can start working towards it.

[saharsh-agrawal]

You may continue.

[Adi-204]

Key Steps for the College to Use Your Repository:

1. Clone the Repository: The college will clone your repository from the version control system (e.g., GitHub).
2. Set Up the .env File: They will add their specific Backend_URI (e.g., the URL for their authentication service) in the .env file
3. The college can manually insert their institution's details, including locations, into the Institute collection in MongoDB.

I have done changes in code and replace hardcoded URLs but I am confused about purpose of instituteSchema, because college will manually insert their institution's details including locations and we will display locations using an utilis function which request to database and get locations. So basically for now I need instituteSchema only for locations which is not making a lot of sense. How should I processed ?

[saharsh-agrawal]

I see you have mixed up the 2 approaches we discussed earlier. Please rethink.

For the second approach that we plan to develop finally, there is no need for anyone else to clone the repo, make manual changes to the code and host it themselves. Our project will handle the various colleges on its own. The pipeline I have in mind is that if a student finds that his/her college is not yet listed, they may request us to add their college, providing all the details and necessary auth endpoints (or the format of institute email, which we may then use to send OTP ourselves and verify the domain - but let us focus on just considering that they have a Heimdall-like function for now, which later we might develop completely independently) through some form (even google form would do). This process can eventually then be made more automated where they will upload the data and their college will be activated after verification from one of our project admins (in this case and currently, me). We might need to come up with a small admin panel also later to add/edit/monitor the various colleges and do other stuff.

I hope your doubts about InstitutionSchema are clearer. As far as I can see now, we might need to store the following data for each college in that: name, code, locations, emailFormat, getAuthLink, verifyAuthLink.

[saharsh-agrawal]

As I said before, let us start by modularizing the authentication completely separately by making an InstitutionSchema with just one row (for KGP), then we can build on it and generalize it for other colleges.

[saharsh-agrawal]

Yeah, now we have some real stuff to work on!

It is a great beginning, although not complete and foolproof!

Let us connect on Slack to discuss this in more detail: https://slack.metakgp.org/.

Please create a thread in the Projects channel and tag me there.