laravel / fortify Goto Github PK

Fortify::routes();

We can use this multiple time in route file like this,

Fortify::routes();

Route::prefix(admin)->namespace('Admin')->name('admin.')->group(function () {
    Fortify::routes(['register' => false]);
});

Route::prefix(staff)->namespace('Staff')->name('staff.')->group(function () {
    Fortify::routes(['register' => false]);
});

Revieving this line (also 70, 72, 74)

return __('The :attribute must be at least '.$this->length.' characters.');

it's very difficult translate with the param. Isn't it easier to write it as

return __('The :attribute must be at least :value characters.', ['value' => $this->length]);

?

It is hard to tell whether this is intentional or not, but composer.json of this library does not contain any "illuminate/*" library constrait at all.

This might be flexible of course, but it is hard to determine, which Laravel version can match the particular version of this library.

I suggest the following line should be added to the composer.json:

{
    ...
    "require": {
        "illuminate/support": "^7.0 || ^8.0",
        ...
    }
}

• Fortify Version: 1.5.0
• Laravel Version: 8.6.0
• PHP Version: 7.4.7
• Database Driver & Version:

Description:

When I disable all the features within the fortify.php configuration file

    'features' => [
        //
    ],

the default Fortify routes are disabled, but the password confirmation route is still enabled. Is this a bug, or is it intentionally defined that way?

Steps To Reproduce:

1. Run laraven new app
2. Run composer require laravel/fortify
3. Run php artisan vendor:publish --provider="Laravel\Fortify\FortifyServiceProvider"
4. Go to config/fortify.php and remove all keys within features array
5. Run php artisan route:list

I think there should be a conditional that groups these routes in the routes.php file.

• Fortify Version: 1.4.1
• Laravel Version: 8.0
• PHP Version: 7.4.5
• Database Driver & Version: MySQL 8.0.19

Description:

When a user updates their profile information, the UpdateUserProfileInformation action checks to see if the new email in the request equals the user's existing email on record. Regardless of rather it does or not, the action sets the user's email_verified_at property to null. The expected behaviour would be to only nullify email_verified_at if the new email in the request does not equal the user's existing email on record.

Steps To Reproduce:

• Setup the latest version of Fortify
• Submit a PUT request to /user/profile-information with any email and name.

I'm facing a problem with Fortify Routes knowing that they are not exposed on Auth::routes() like Laravel UI. I want to populate Fortify Routes in a route group to enable route globalization. For instance...

Route::localized(function () {
     // Fortify Routes here
});

I localized my projects by prefix URL with a locale symbol. How I can do it with fortify to be like 'en/login', 'en/register', ... etc?

We can conditionally redirect the user to different routes based on user attributes by creating a custom LoginResponse and binding our own response instead of the Fortify response.

Can we have the same for the TwoFactorLoginResponse so that this can be replaced also?

• Fortify Version: 1.5.0
• Laravel Version: 8.6.0
• PHP Version: 7.4

During the implementation of the password confirmation functionality, I noticed the request is not validated beforehand to see if the required password is actually submitted. Resulting in a server error:

TypeError
Argument 3 passed to Laravel\Fortify\Actions\ConfirmPassword::__invoke() must be of the type string, null given, called in /var/www/projects/laravel/vendor/laravel/fortify/src/Http/Controllers/ConfirmablePasswordController.php on line 53 

If you submit an empty password field, the validation should just fail, as if you submitted an invalid password. It should not actually result in a server error.

Will Laravel Fortify gets a documentation website in the near future?

This will be very convenient to write our own implementations of an authentication system.

I think it would be nice to have, either a global configuration or a configuration at the feature level to enable only "api" routes.
I am using Fortify with a SPA so I don't need the views shipped with it and it's quite "annoying" when I run php artisan route:list.

I am ready to start the development if this feature is approved 😄

Please, find examples below:

/*
 |--------------------------------------------------------------------------
 | Disabling views 
 |--------------------------------------------------------------------------
 |
 | ...
 |
 */

  'disableViews' => false,

or

'features' => [
    Features::registration(['disableViews' => true]),
],

I am new to fortify, but would like to require a password contain at least one of a configurable set of symbols like '#', '$', '%', '_', '-','+', etc.

I was looking at the source, and there is a Fortify Rule named Password, and it's missing the logic I want/need. I could write another Fortify Rule to take this into account, but it would nice to have it out of the box in order to create really strong passwords.

Also, is there someplace special where these rules ought to go, specially if we want to tweak the current ruleset?

I like to place my login endpoints behind a prefixed path. (& honeypot common endpoints 😉 )

I'm surprised to see that both Fortify and Jetstream boot their routes inside src/FortifyServiceProvider, instead of from a user's route declaration like how Auth::routes() worked.

Perhaps merging the existing group options with an array found in config/fortify.php?

    'route_options' => [
        'prefix' => 'secret', // This makes the login page /secret/login
        /* 'domain' => null, */
    ],

I want to fire an event to update last login time can you suggest me the best way to fire an event once authentication passes?

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?

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:

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:

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, DirectoryTree/LdapRecord-Laravel#196

• Fortify Version: 0.0.1
• Laravel Version: 8.x-dev
• PHP Version: 7.4.10
• Database Driver & Version: pgsql 12

Description:

When trying to cache the routes a LogicException is thrown stating that.

Unable to prepare route [register] for serialization. Another route has already been assigned name [register].

Steps To Reproduce:

Run:

laravel new routenametest--jet --dev

cd routenametest

php artisan route:cache

It's possible to customize AuthController?
Where is the definition of x-jet-input etc in a jestream inertia stack?

The validation in the CreateNewUser class uses the exact same password rules as defined in the PasswordValidationRules trait.

Would it be nice to use the PasswordValidationRules trait in CreateNewUser action?

it would be great if we can add multiple login using custom guard. is that possible? currently i still doing the old way on admin authentication.

Laravel Version: 8

How I can disable auto login after registration ?

I think I needs to override store method, but how ?

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."

• Fortify Version: 1.5.0
• Laravel Version: 8.6.0
• PHP Version: 7.3

Description:

I'm unsure if this is a Fortify issue or a Laravel issue or even me not using middleware correct, however in my config/fortify.php I have 'home' => RouteServiceProvider::HOME, and in my RouteServiceProvider I have public const HOME = '/home'; yet when I try logging in I get sent to my /not-subscribed route. If I comment out my / route, I get sent to /home. If I put Route::view('/home', 'home'); above the / route I get sent to /home.

My route looks like the following, and yes I do want every route to have an authenticated user.

Route::middleware(['auth'])->group(
    function () {
        Route::middleware([MyCustomMiddleware::class])->group(
            function () {
                Route::get(
                    '/',
                    function () {
                        return view('welcome');
                    }
                );
            }
        );
        Route::view('/home', 'home');
        
        Route::get('/not-subscribed', NotSubscribedIndexAction::class)->name('auth.notsubscribed');
    }
);

As you might have seen, my / route does have a middleware on it, which is why I get redirected to /not-subscribed upon login when having my routes in that order.

I also did a test where I strictly had the following and it does work correctly, so again, I'm unsure if this is a Fortify issue, Laravel issue, or me not using middleware correctly.

        Route::get(
            '/',
            function () {
                return view('welcome');
            }
        );
        Route::view('/home', 'home');

After succesfully update of profile information the status is set to 'profile-information-updated'

This string is not even possible to translate.

In my case I have in my main layout something like:

        @if (session('status'))
            {{ session('status') }}
        @endif

And can't even translate that string because the status can be already translated or have different namespace of translation.

Can we add a translated string there? Override that controller for just change that string seem not worth.

In Jetstream you seem just return a generic "Save" message from Livewire, but non-livewire and non-ajax submission need a way to display message from server.

Same thing for update password and two factors. Return 'password-updated' and 'two-factor-authentication-enabled'

Thanks

• 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"

Hello,

this is more an enhancement suggestion and not an actual bug. It seems that most users would expect that route('forgot-password') would work in an href (or form action). However, the name of the route is password.request for GET requests and password.email for POSTs. I think this is somehow misleading and it could be improved.

Thank you.

In lot of projects we do have multiple user tables based on requirement, so, it is not feasible to have single user table in this scenario. Result is multiple tables in database storing credentials for different roles.

In this case till now we used to specify custom guard in config/auth.php in Laravel for each credential table and use them to build multi-auth system. However, Jetstream is using single guard specified in Fortify.php.

Request: Please provide option to choose guard specified in config/auth.php to create a multiauth system instead of using single guard from fortify.php. At present, we are forced to use only one guard specified in fortify.php to use in application. Please help !!

Would be nice to have an option to remember the 2fa code for e.g 7 days for a device.

Plesk for example is doing something similar (the days are configurable in this case):

It would be nice if it was possible to make it so only logged in users can register new account, prefferably with only one line of code

• Fortify Version: 1.4.0
• Laravel Version: 8.4.0
• PHP Version: 7.4.3
• Database Driver & Version:

Description:

TypeError
Argument 1 passed to Symfony\Component\HttpFoundation\Response::setContent() must be of the type string or null, object given, called in laravel\framework\src\Illuminate\Http\Response.php on line 65

I did some debugging, and basically when you return an Inertia response in a common controller Illuminate\Routing\Router::toResponse() receives Inertia\Response object where then it calls its own toResponse() to return Illuminate\Http\Response and all is good.

But, using:

Fortify::loginView(function () {
    return inertia('Auth/Login');
});

it fails to build the response because of the SimpleViewResponse and simply returns and Inertia\Response object instead of a string, hence the error above.

Steps To Reproduce:

Configure Inertia, make a Vue component resources/js/Pages/Auth/Login.vue and in FortifyServiceProvider::boot() paste:

Fortify::loginView(function () {
    return inertia('Auth/Login');
});

Right now if we want to change the login view we can do

Fortify::loginView('different-view')

But that only allows you to change it to a different view name, behind the scenes it's just rendering a singleton binding for LoginViewResponse.

You'd think no stress, we can override that binding for example for an Inertia view

$this->app->singleton(LoginViewResponse::class, () => Inertia::render('Login'));

But unfortunately this doesn't work due to the typehint on the controller method

So instead the next best option is resolving an anonymous class that proxies the inertia response

$this->app->singleton(LoginViewResponse::class, function () {
    return new class implements LoginViewResponse
    {
        public function toResponse($request)
        {
            return Inertia::render('Login')->toResponse($request);
        }
    };
});

This works perfectly but isn't exactly friendly.
My suggestion is that we loosen the typehint to just Response and allow Fortify::loginView to take a closure which would be used as the binding, meaning it would be as simple as

Fortify::loginView(() => Inertia::render('Login'));

Of course we'd do the same for the other view methods. I'm happy to PR this if the idea gets approved.

I'm trying to rebuild a specific authentication implementation we were using in Laravel 7 with Fortify, however, there doesn't seem to be a way to modify the authorisation error message returned to the user within the Fortify::authenticateUsing() method.

For example:

$user = User::where('username', $request->username)->first();

if ($user && in_array($user->status_id, [1,2,3])) {
    if (Hash::check($request->password, $user->password)) {
        return $user;
    }
}
else {
    // custom error message here -- doesn't work
    $request->session()->flash('errors', 'Account does not exist or is inactive. Check your username.');
}

I've traced this back to the Laravel/Fortify/Actions/AttemptToAuthenticate class and the throwFailedAuthenicationException function which allows you to customise the message via the resources\lang\en\auth.php file, but there doesn't seem to be a way of modifying the logic of which message should be returned anywhere?

If I'm wrong, could the documentation be updated to show how?

Recently i see the PR #70 to get a better way to translate those strings and I really appreciate that, but what if a want to custom that messages? Maybe a way to achieve that is with lang files or a possibility to change it in ValidationRules action published.

Option to build the Auth Migrations and link with UUID instead of Standard incrementing Primary key, this for all migrations

• Fortify Version: 1.5.0
• Laravel Version: 8.6.0
• PHP Version: 7.4.8
• Database Driver & Version: MySQL 5.7

Description:

Upon installing Laravel/Fortify on a clean install, you receive errors on the login and register endpoints.

Errors, respectively;

Target [Laravel\Fortify\Contracts\LoginViewResponse] is not instantiable.

and

Target [Laravel\Fortify\Contracts\RegisterViewResponse] is not instantiable.

Steps To Reproduce:

laravel new project
cd project
composer require laravel/fortify
php artisan vendor:publish --provider="Laravel\Fortify\FortifyServiceProvider"
php artisan migrate

It would be handy if there was a way to customize the logout function .!
so if we have multiple guard then we can limit the function to log out the user only not the admins.

Hi,

I totally love the default options we've with Laravel Fortify, however it would be nice to be able to change the registered routes uris. Currently you're stuck with the default naming convention which is based on the English language.

In my opinion it would be fantastic to have a configurable option within config/fortify.php. Lets say something like this:

'routes' => [
    'login' => 'inloggen',
    'register' => 'registreer',
    ...
],

My current workout is to not use any registered routes, and create the routes myself in the routes/web.php file of the Laravel project itself.

Right now you can't disable registration without also disabling login.
I'd like to disable new registrations, but want existing users to be able to continue to login.

Current config/fortify.php
Features::registration(),

Suggested config/fortify.php
Features::registration(), Features::login(),

• Fortify Version: 1.3.1
• Laravel Version: 8.1.0
• PHP Version: 7.4.9
• Database Driver & Version: MySQL

Description:

When running The laravel installer or jetstream install command, the CreateNewUser Fortify Action generated does not match the stub within the fortify project.

For example. within the fortify package the CreateNewUser Fortify Action uses the proper PasswordValidationRules trait for the password validator. When that stub is published to my project, the CreateNewUser Action does not use the PasswordValidationRules trait and instead has 'password' => ['required', 'string', new Password, 'confirmed'],

I've tried removing any composer cache but it continues to happen.

``

Steps To Reproduce:

laravel new laravel8-jet --jet

Select inertia, and no teams

OR

laravel new laravel8-jet
composer require laravel/jetstream
php artisan jetstream:install

Now view the laravel8-jet/app/Actions/Fortify/CreateNewUser file and compare to the package's stub version.

I've also attached a screenshot:

EDIT: This actually looks like it may be a jetstream problem as the CreateNewUser stub within that package looks out of date with Fortify. I will keep this here just in case you decide to keep this open and I'm incorrect but it looks like it's unrelated to this project. Opening a ticket in the jetstream repo: laravel/jetstream#167 Thanks

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.

• Fortify Version: 1.4.3
• Laravel Version: 8.5.0
• PHP Version: 7.4
• Database Driver & Version:

Description:

Verification status message is incorrect

Steps To Reproduce:

Request email verification to be sent

return $request->wantsJson()
                    ? new Response('', 202)
                    : back()->with('status', 'verification-link-sent');

• Fortify Version: 8.4.0
• Laravel Version: 8.4.0
• PHP Version: 7.3.9
• Database Driver & Version: 5.7.x

Description:

Undefined variable: request in reset-password.blade.php when I override view forgot-password

Steps To Reproduce:

Clean installation Laravel Framework 8.4.0 without any auth scaffolding.

Db migration and seed - it's ok!

Then:

composer require laravel/fortify

and php artisan vendor:publish...

php artisan migrate

It's ok!

Created in FortifyServiceProvider in boot() :

Fortify::requestPasswordResetLinkView(function () {  
  return view('admin.auth.forgot-password');  
});  
  
Fortify::resetPasswordView(function () {  
  return view('admin.auth.reset-password');  
});

And created views in view/admin/auth folder:
forgot-password.blade.php

<form method="POST" action="/forgot-password">  
  @csrf  
  <input id="email" type="email" name="email" value="{{ old('email') }}" required>  
  <button type="submit">  
  {{ __('Send Password Reset Link') }}  
  </button>  
</form>

reset-password.blade.php

<form method="POST" action="/reset-password">  
  @csrf  
  <input type="hidden" name="token" value="{{ $request->route('token') }}">  
</form>

Then in browser /forgot-password Send Password Reset Link

From mail go to link /reset-password/543c9a...hash?email=admin%40example.com

I get

ErrorException
Undefined variable: request (View: ...\resources\views\admin\auth\reset-password.blade.php)`

It also doesn't work if I am using Jetstream and want to override the view forgot-password in JetstreamServiceProvider in boot() and sets any folder.

Even if I only specify this, I will not change anything else from a clean install (liveware).

Fortify::requestPasswordResetLinkView(static function () {
    return view('auth.forgot-password');
});

At the moment it is impossible to verify that the user activated 2fa in his device.
It should be mandatory that the user has to confirm the activation with an actual 2fa code.
This is not possible at the moment because in "Laravel\Fortify\Actions\EnableTwoFactorAuthentication" the database field is filled on activation. The generation of the secret has to be done before and the secret has to be an option in the action so it is possible to check a valid code before the secret is saved to the database.

related to https://github.com/laravel/jetstream/issues/74

Hello there. I want to customize the controls and requests, but I cannot do the customizations in the vendor because requests and controls files are not sent in shared files.

• Fortify Version: 1.6.1
• Laravel Version: 8.9.0
• PHP Version: 7.4.9
• Database Driver & Version: MySQL 5.7.31

Description:

This is the first time I'm using Fortify. I was trying to customize the login flow, because I want to change the default error bag on the ValidationException. But I noticed that the throwFailedAuthenticationException method on the AttemptToAuthenticate action is not being called, because the RedirectIfTwoFactorAuthenticatable action is calling validateCredentials, despite that I'm not using 2FA.

So the login pipeline is stopping at RedirectIfTwoFactorAuthenticatable::validateCredentials(), and the AttemptToAuthenticate, does not do anything, even though it's supposed to attempt to login or throw a validation exception.

Steps To Reproduce:

1. Override AttemptToAuthenticate:

use Illuminate\Validation\ValidationException;
use Laravel\Fortify\Actions\AttemptToAuthenticate;

class CustomAttemptToAuthenticate extends AttemptToAuthenticate 
{
    protected function throwFailedAuthenticationException($request)
    {
        try {
            parent::throwFailedAuthenticationException($request);
        } catch (ValidationException $e) {
            throw $e->errorBag('login');
        }
    }
}

2. Override login pipeline:

Fortify::loginThrough(function () {
    return [
        config('fortify.limiters.login') ? null : EnsureLoginIsNotThrottled::class,
        RedirectIfTwoFactorAuthenticatable::class,
        CustomAttemptToAuthenticate::class,
        PrepareAuthenticatedSession::class,
    ];
});

3. Test the custom error bag:

$response = $this->post('login', [
    'email' => '[email protected]',
    'password' => 'password',
]);

 // this assertion fails
$response->assertSessionHasErrors('email', null, 'login');

4. Note the exception stack trace:

$this->withoutExceptionHandling();

1   vendor/laravel/fortify/src/Actions/RedirectIfTwoFactorAuthenticatable.php:98
    Illuminate\Validation\ValidationException::withMessages()

2   vendor/laravel/fortify/src/Actions/RedirectIfTwoFactorAuthenticatable.php:80
    Laravel\Fortify\Actions\RedirectIfTwoFactorAuthenticatable::throwFailedAuthenticationException()

3   vendor/laravel/framework/src/Illuminate/Support/helpers.php:263
    Laravel\Fortify\Actions\RedirectIfTwoFactorAuthenticatable::Laravel\Fortify\Actions\{closure}()

4   vendor/laravel/fortify/src/Actions/RedirectIfTwoFactorAuthenticatable.php:82
    tap()

5   vendor/laravel/fortify/src/Actions/RedirectIfTwoFactorAuthenticatable.php:50
    Laravel\Fortify\Actions\RedirectIfTwoFactorAuthenticatable::validateCredentials()

6   vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php:167
    Laravel\Fortify\Actions\RedirectIfTwoFactorAuthenticatable::handle()

7   vendor/laravel/fortify/src/Actions/EnsureLoginIsNotThrottled.php:39
    Illuminate\Pipeline\Pipeline::Illuminate\Pipeline\{closure}()

8   vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php:167
    Laravel\Fortify\Actions\EnsureLoginIsNotThrottled::handle()

9   vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php:103
    Illuminate\Pipeline\Pipeline::Illuminate\Pipeline\{closure}()

10  vendor/laravel/fortify/src/Http/Controllers/AuthenticatedSessionController.php:60
    Illuminate\Pipeline\Pipeline::then()

Hi,

It would be a really nice feature to have if we could call a custom function once the user is authenticated successfully. An example would be to store some data in session variables once the user logs in to the application. A similar function while logging out would also be helpful, such as clearing the session variables on user logging out.

Thanks

Im looking into adding Single Sign On support in Fortify. If we had the ability to add extra steps in the pipeline shown in the below code from Laravel\Fortify\Http\Controllers\AuthenticatedSessionController, then its extensible to add SSO or other auth methods into the mix.

public function store(LoginRequest $request)
{
    return (new Pipeline(app()))->send($request)->through(array_filter([
        config('fortify.limiters.login') ? null : EnsureLoginIsNotThrottled::class,
        RedirectIfTwoFactorAuthenticatable::class,
        AttemptToAuthenticate::class,
        PrepareAuthenticatedSession::class,
    ]))->then(function ($request) {
        return app(LoginResponse::class);
    });
}

agree?

In laravel/ui package we have function guard() to custom guard, can we add it to fortity ?

I haven't found any ways to override the register, login and logout paths. For some projects it would be nice to use localized paths (e.g. l8.test/logg-inn).

Would it be a solution to add the paths to the fority.php config file:

'paths' => [
        'create_user' => '/opprett'
    ]

and then in the fortify route-file:
Route::get(config('fortify.paths.create_user')