Backend controllers and scaffolding for Laravel authentication.

• Version: v1.7.4
• Laravel Version: v8.22.1
• PHP Version: v7.4.13

Description:

The current two factor authentication solution sets 2fa to enabled without requiring a confirmation (via TOTP) that the authenticator app is actually set up.

Steps To Reproduce:

The current solution works like this:

1. POST /user/two-factor-authentication, the user's two_factor_secret is stored. (2fa is now enabled!)
2. GET /user/two-factor-qr-code, show QR code and ask user to scan the code with their app.
3. GET /user/two-factor-recovery-codes, show recovery codes and ask the user to save them.
4. User abandons the process before setting up their authenticator app or saving the recovery codes and is now locked out of their account.

They could abandon the process because they first need to choose one of the many TOTP generators in the app store, and get side tracked, or their session times out, or they click the back button, or close their tab, or their computer crashes, ... Definitely 2fa must not be enabled before it is confirmed by a generated OTP.

How To Fix It:

1. GET /user/two-factor-qr-code generates a QR code from a new two factor secret that is stored in the session.
2. GET /user/two-factor-recovery-codes, show the recovery codes to the user, ask them to save them.
3. The user is asked to set up their authenticator app with this QR code and enter a resulting TOTP code. This confirms that they have set up their authenticator (else they cannot generate a valid code), and can also (by written explanation) be used as confirmation that recovery codes were stored in a safe place.
4. POST /user/two-factor-authentication, receives a new parameter: code. The code is validated using the two factor secret stored in the session.
5. If the code is valid, the two factor secret from the session is written into the user table (= enabling 2fa, now for real). If not, then the response indicates that the user did not enter a valid code and must re-try.

It would be nice to offer customization options for redirection such as Fortify::redirectAfterLoginUsing($callback) or Fortify::redirectAfterRegisterUsing($callback). This would bring back laravel/ui redirectTo capabilities. What do you think ? Do you prefer to encourage people to use custom Response classes and to put them under app/Http/Responses/Fortify ?

Concerning the registration use case, maybe it's pretty common to redirect users to a tour/guide page, so what do you think about a dedicated configuration key to set the path ?

Would you be interested in a PR that adds webauthn (Security Keys and TouchID) support to Fortify and Jetstream? Would be awesome to have something like this out of the box.

Currently you are unable to use the VerifyEmailController with Fortify if you want to have an SPA which doesn't use Laravel's view templates. The reason for this is Laravel set's the route middleware to be signed and doesn't allow for using signed:relative. Also the VerifyEmailController currently only redirects to the home url set in the config template.

This PR enables a config variable for setting signed:relative but defaults to signed and returns json within the VerifyEmailController if the request wantsJson.

I know this is extremely early since this just got released -- but I'm wondering if there's any plans on adding the ability to override the included actions, or for the actions to utilize other authentication providers besides eloquent?

The current RedirectIfTwoFactorAuthenticatable action uses a getModel() method that is not currently inside the Stateful guard contract:

https://github.com/laravel/fortify/blob/f29ed3f63d6da006fb540e2894e4aa387ccabde2/src/Actions/RedirectIfTwoFactorAuthenticatable.php#L51

This action (RedirectIfTwoFactorAuthenticatable) is also responsible for validating the users credentials -- but isn't the authentication UserProvider responsible for this?

https://github.com/laravel/framework/blob/c87794fc354941729d1f0c4607693c0b8d2cfda2/src/Illuminate/Contracts/Auth/UserProvider.php#L48

The other concern is that the AttemptToAuthenticate action only allows customization of the username passed into the $guard->attempt() method, while Laravel UI allows you to customize the whole array of credentials passed in:

AttemptToAuthenticate Action in Fortify: https://github.com/laravel/fortify/blob/4be99538e23fc4a04a4cbf305ab055f2e52537b6/src/Actions/AttemptToAuthenticate.php#L46-L53

AuthenticatesUsers Trait in Laravel UI: https://github.com/laravel/ui/blob/6ed3b97576fc99049ba576de4cfab5cef4771ab3/auth-backend/AuthenticatesUsers.php#L93-L96

Please don't take these questions in any sort of negative manor -- I'm immensely grateful for the insane amount of free work that was put into this! ❤️

If there is interest in this possibility, I can work on a PR to add this extensibility and you can look at it to see if it's something you like / don't like. If it's denied, no hard feelings 👍

Related: #16, https://github.com/DirectoryTree/LdapRecord-Laravel/issues/196

• Fortify Version: 0.0.1
• Laravel Version: 8.x-dev 02522b0
• PHP Version: 7.3.21
• Database Version: 8.0.19

Description:

Illuminate\Contracts\Container\BindingResolutionException Target [Laravel\Fortify\Contracts\CreatesNewUsers] is not instantiable.

Steps To Reproduce:

Windows environment

laravel new jetstream --jet --dev select livewire and teams php artisan migrate php artisan serve

Register a new user and click "Register"

after installation completed, and once you run the migrate command, enabling the Two-Factor confirmation feature will break the Two-Factor "Disable" button at least.

Column not found: 1054 Unknown column 'two_factor_confirmed_at' in 'field list'

• Fortify Version: 1.8
• Laravel Version: 8.65
• PHP Version: 8.0
• Database Driver & Version:

Description:

The Fortify::authenticateUsing method is triggered twice for each request.

Steps To Reproduce:

In FortifyServiceProvider create an index: protected $i=1;

In boot method add tis function:

    Fortify::authenticateUsing(function (Request $request) {
        $this->i++;

        if( $this->i > 2){
            dd('hmm', $this->i);
        }
        $user = User::where('email', $request->email)->first();
        if ($user && Hash::check($request->password, $user->password)) {
            return $user;
        }
    });

    Fortify::loginView(function () {
        return view('user::auth.login');
    });

You will get: "hmm" 3

Using laravel/UI we can create authentication scaffold on multiple places or for multiple users like admin, normal users by copy-pasting the same scaffold generated by the --auth flag.

How can we achieve the same with fortify?

How can we use forify to authorize admin and normal users?

Description:

When performing a password reset, users enter an email address and the request gets posted to /forgot-password. If someone enters an email that doesn't exist, Fortify returns an error. If the email does exist, it returns a status message that the email has been sent.

This exposes whether or not an account exists on the system which provides an attacker with information. They can now target that user/email address directly with phishing or social engineering attempts.

Best practice would be to skip returning any errors and to always notify users that "An email has been sent to [email protected] with password reset instructions."

As you can read at #163

According to:

https://tenancyforlaravel.com/docs/v3/early-identification

Using constructor DI avoids tenancy route middleware to works. The reason is Constructor DI is executed before middleware.

AFAIK the proposed changes will solve the issue and will make building web apps with Laravel Tenancy package and Fortify/Jetstream easier but feel free to close this PR for any reason...