-
Notifications
You must be signed in to change notification settings - Fork 2
Risks
Below are listed potential risks that can come during the development of the project. Some solutions are mentionned, but these need to be assessed in depth.
Building an authentication system allowing EPFL-only users will come with several obstacles. There are three auth providers that could be used, namely Tequila, Google, or Microsoft.
Tequila and Microsoft may not allow authentication requests from foreign applications. This leads to using Google, but doing that would prevent accessing metadata about the profile (e.g. joined associations etc.). However the metadata can still be manually fetched from search-api.epfl.ch/api/ldap.
Using Google also adds an additional layer of verification to the account creation, to prevent signing up with a non-epfl.ch email. Using Firebase Cloud Functions to create accounts may be a solution to that issue.
As the project evolves, the team needs to clearly define any modification made from the design planned initially, review it with other team members and modify the Figma in accordance to the new design. A protocol needs to be put in place, otherwise the project could suffer a global lack of coherence.
To model relationships between Users and Associations, a typical representation would be using join tables in an SQL database. However, Firebase Firestore doesn't natively support this, so another solution must be found. Two main factors need to be considered before implementations; performance vs SSOT.
The approach that would have the best performance is the following:
- Users have a
users/{userId}/followingAssociations/collection containing documents about each association they follow. - Associations have a
associations/{associationId}/followers/collection containing documents about each of their followers.
The downside to this approach is that the database has several sources of truth, that may conflict if write requests are not correctly sent.
In order to keep a single source of truth, the following database architecture is suitable:
- There exists a
followings/${followingId}collection that contains documents with theuserIdand theassociationIdof the follow relationship.
While this prevents data-duplication, querying the collection will become slower and slower as new follow relationships are created. A hybrid approach may be needed for the project.
Imagine user A has the email a@gmail.com. Then, the evil user E signs up on Unio, but uses A's email address. E of course cannot verify the email address, but the account is still created. If A then tries to create an account with his own email address, it will fail because an account with that email already exists. Furthermore, A cannot login into his own account because he doesn't have the password E used.
This is a potential risk, and one solution to this would be to add a "reset password" button that sends a password reset link by email, so that A could regain access to his account. Note that E can only create the account and cannot perform actions on behalf of A, because all actions require a verified email. Additionally, accounts with unverified email addresses could be deleted after a certain period of time, but that requires server-side computation.