feat: utils for two factor auth modal

[ttebify]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes #311

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I documented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[ttebify]

Here is what I noticed while working on this feature.

The current implementation of the 2FA authentication flow in our application is causing an unnecessary step for our users. After a user verifies their 2FA at login, the application writes the state to the Redis store. However, when a user logs in, the application already checks the Redis store and returns that the user has been verified, which means the 2FA modal is never shown.

How can we fix this? I suggest that we stop relying on the user's verification state stored in Redis. Instead, we should require the user to verify themselves every time we need to perform critical actions that require verification.

The current implementation does not address these issues, I have created it as a draft first for us to go over and propose ways in which we can properly handle user verification.

[dahal]

The current implementation of the 2FA authentication flow in our application is causing an unnecessary step for our users. After a user verifies their 2FA at login, the application writes the state to the Redis store. However, when a user logs in, the application already checks the Redis store and returns that the user has been verified, which means the 2FA modal is never shown.

This is intentional, to avoid asking 2FA to users too many times when they are logging in from same device. We use fingerprint to identify if user is using same device or different. The util however, when triggered should open every time if the user has enabled 2fa (regardless of whether or they have verified.)

[ttebify]

The current implementation of the 2FA authentication flow in our application is causing an unnecessary step for our users. After a user verifies their 2FA at login, the application writes the state to the Redis store. However, when a user logs in, the application already checks the Redis store and returns that the user has been verified, which means the 2FA modal is never shown.

This is intentional, to avoid asking 2FA to users too many times when they are logging in from same device. We use fingerprint to identify if user is using same device or different. The util however, when triggered should open every time if the user has enabled 2fa (regardless of whether or they have verified.)

Ok that makes sense, does it mean that here:

// Check two-factor auth status
if (user.twoFactorEnabled && !twoFactorVerified) {
  setOpenModal(true);
} else if (twoFactorVerified) {
  // Two-factor auth already verified, execute the original function
  await fn();
} else {
  // Two-factor auth disabled, execute the original function
  await fn();
}

I can do without checking if twoFactorVerified is false?

[Aju100]

Hey @ttebify , one test case is failed out there for PR title validation. Can you please update the PR title where suggestions are being given by github bot.

[ttebify]

Hey @ttebify , one test case is failed out there for PR title validation. Can you please update the PR title where suggestions are being given by github bot.

Sure, I'll do that thanks

[dahal]

Impressive work @ttebify 🏅 🎉