Add Two Factor Authentication for React Starter Kit

[pushpak1300]

This MR adds Two-Factor Authentication (2FA) functionality to the React Starter Kit using Laravel Fortify's built-in support for 2FA

🔒 Backend Changes

We are now leveraging Fortify for handling two-factor authentication. Since Fortify provides additional security features out of the box, this MR also replaces our custom implementation of the password confirmation page with Fortify’s native confirm password functionality.

Previously: Custom password confirmation
Now: Native Fortify confirm-password implementation

🖥️ Frontend/UI Updates

The UI has been updated to handle all the two-factor settings based on Fortify's configuration. The following Fortify features are enabled:

Features::twoFactorAuthentication([
    'confirm' => true,
    'confirmPassword' => true,
    // 'window' => 0
]),

Demo

https://www.loom.com/share/6bf836eccae84778a511916a9d02bb59?sid=efb1fac2-7482-40ec-82e6-31f0b3fa77a8

Co-authored-by: Tony Lea [email protected]
Thanks to #101

[ludo237]

I think this is better be its own starter kit

[pushpak1300]

Waiting until we fix this bug in the Inertia <Form> component inertiajs/inertia#2558, as it will clean up a few unnecessary parts.

[OliverSpeak]

Why is this using Fortify? I don't see how it makes sense to use part of that package when the rest of the authentication is already handled by open code.

[Diddyy]

Waiting until we fix this bug in the Inertia <Form> component inertiajs/inertia#2558, as it will clean up a few unnecessary parts.

Its been merged!

[pushpak1300]

Its been merged!

Hey It's needs to be tagged with new release in order to use it. I'm tracking it and will push changes once tagged.

[ludo237]

Why is this using Fortify? I don't see how it makes sense to use part of that package when the rest of the authentication is already handled by open code.

Don't bother they won't listen. Just wait for a maintainer to close this

[tnylea]

Thanks for the shout out @pushpak1300 😁

Excited to see this released 👍

[joetannenbaum]

Why is this using Fortify? I don't see how it makes sense to use part of that package when the rest of the authentication is already handled by open code.

We decided to use Fortify because it's battle tested and the likelihood of anyone changing the underlying code (not the views, which are open code) are very slim. We did not want to burden the user with maintaining this code, we instead opted for a composer update for bug fixes as the come up.

[joetannenbaum]

Why is this using Fortify? I don't see how it makes sense to use part of that package when the rest of the authentication is already handled by open code.

Don't bother they won't listen. Just wait for a maintainer to close this

Sorry you feel this way. This PR will be merged once it's ready.

[joetannenbaum]

Did a first pass here, I haven't run it locally, just looked at the code. I'll spin it up in the next round and we'll keep refining 👍

[joetannenbaum]

Mostly minor stuff. The "negative first" comments are mostly just about reducing cognitive overhead when looking at code. There are times when negative-first makes the most sense, but in most cases here I would argue that it's clearer to read when going from true to false.

The exception being, in my book, that if the statements of one of the conditions are vastly shorter than the other, that one should go first so it's easier to track the if statement through to the end.

[Diddyy]

I'm loving following these updates, @joetannenbaum is helping me learn, I really enjoy watching this process in public.
Looking forward to the release guys! Great work :D

[joetannenbaum]

Instead of console.error can we actually float these messages up to the UI somehow so that we display them to the user? We shouldn't be console.erroring at this level.

Even just error(s) state that gets returned from the hook or something