You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a student enrolled to begin my course abroad shortly I want to sign in to Louffee So that I can find the perfect home during my studies.
Acceptance Criteria ✅
Given that the user is on Sign In page When they wish to sign in to Louffee with their Google account Then they shall be able to log in by authorising Louffee to have access to minimal info, i.e., email, phone.
Given that the user is on Sign In page When they wish to sign in to Louffee with their Apple ID account Then they shall be able to log in by authorising Louffee to have access to minimal info, i.e., email, phone.
Notes 📝
We will not allow the users to sign in with their email address and password since it is discouraged due to inherited leaking risks.
The user must provide a username because, soon, the user will be able to access other user's profile pages via a handle.
Technical Refinement 🎧
We've commenced this project with the Next Auth as the authentication handler and Google would be our authentication provider.
However, to facilitate the integration and configuration to add new vendors if necessary, the complexity of implementing Next Auth would vertically scale since Next Auth is not a service provider and, therefore, we'd have to create a schema and tables in the database to control and store the user's metadata.
To provide more security and avoid further potential issues with the implementation, we've picked Clerk due to its smooth integration and good User Experience associated with the security aspects of our users.
The text was updated successfully, but these errors were encountered:
This commit introduces the Clerk authentication service to the project.
It replaces the NEXTAUTH environment variables with the new Clerk
environment variables. The following commits will structure the
Clerk authentication service and the implementation in the `@louffee/auth`
internal package.
This commit is part of the issue #2.
User Story 👤
As a student enrolled to begin my course abroad shortly
I want to sign in to Louffee
So that I can find the perfect home during my studies.
Acceptance Criteria ✅
Given that the user is on Sign In page
When they wish to sign in to Louffee with their Google account
Then they shall be able to log in by authorising Louffee to have access to minimal info, i.e., email, phone.
Given that the user is on Sign In page
When they wish to sign in to Louffee with their Apple ID account
Then they shall be able to log in by authorising Louffee to have access to minimal info, i.e., email, phone.
Notes 📝
Technical Refinement 🎧
We've commenced this project with the Next Auth as the authentication handler and Google would be our authentication provider.
However, to facilitate the integration and configuration to add new vendors if necessary, the complexity of implementing Next Auth would vertically scale since Next Auth is not a service provider and, therefore, we'd have to create a schema and tables in the database to control and store the user's metadata.
To provide more security and avoid further potential issues with the implementation, we've picked Clerk due to its smooth integration and good User Experience associated with the security aspects of our users.
The text was updated successfully, but these errors were encountered: