Enhance routing with config options

[MarkIvanowich]

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

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.

https://github.com/laravel/fortify/blob/65c695ddcbc29efc1b985fb6a4932daa5c9e80a2/src/FortifyServiceProvider.php#L110-L118

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, */
    ],

[MarkIvanowich]

If the user does enable a prefix, then all the current view paths / links will break.

We could leave this as the user's responsibility to publish and edit. Or we could replace the current static paths with route names:

        {{--<form method="POST" action="/login">--}}
        <form method="POST" action="{{route('login')}}">
            @csrf
            ...

[undjike]

I'm facing a similar problem. I want to populate Fortify Routes in a route group to enable route globalization. For instance...

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

[thecodemill]

Still experimenting, but what I've done is:

app/Providers/FortifyServiceProvider.php

public function register()
{
    Fortify::ignoreRoutes();
}

routes/web.php

Route::prefix('auth')->group(function () {
    require base_path('vendor/laravel/fortify/routes/routes.php');
});

Or you could redefine the routes entirely instead of requiring them.

EDIT: Trying to get past the hard-coded route name in Laravel\Fortify\Http\Responses\PasswordResetResponse::toResponse() is proving tricky.

[c0nst4ntin]

@thecodemill have you continued this approach or found a different way?

[paras-malhotra]

See https://github.com/laravel/jetstream/pull/67, #13 and #15