You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When ran as-is and hence implicitly binding the User model, the redirect works as expected. The redirect() method receives a user id and splices it into the destination URL. As a consequence the {user} parameter is only substituted in the second request (after the redirect).
When explicitly defining the binding, things change:
// app/Providers/RouteServiceProvider.php : boot()Route::bind('user', function ($id) {
returnUser::findOrFail($id); // probably extended with additional query logic.
});
The {user} parameter is now also substituted in the first request, meaning that the framework's RedirectController receives a full user model which it'll be unable to easily splice into the destination URL. Ultimately the application breaks and an exception is thrown.
Writing logic in the binding to check for redirect routes feels rather cumbersome.
I think this is a valid use case for the framework to disable the SubstituteBindings middleware in case of redirect routes... Can't think of any scenario where raw request parameters shouldn't end up in the destination url as-is.
The text was updated successfully, but these errors were encountered:
Propaganistas
changed the title
Parameters in Route::redirect() get resolved differently for implicit/explicit bindings
Parameters in Route::redirect() are handled differently for implicit/explicit bindings
Feb 26, 2023
Description:
Consider the following:
When ran as-is and hence implicitly binding the User model, the redirect works as expected. The
redirect()
method receives a user id and splices it into the destination URL. As a consequence the{user}
parameter is only substituted in the second request (after the redirect).When explicitly defining the binding, things change:
The
{user}
parameter is now also substituted in the first request, meaning that the framework'sRedirectController
receives a full user model which it'll be unable to easily splice into the destination URL. Ultimately the application breaks and an exception is thrown.Writing logic in the binding to check for redirect routes feels rather cumbersome.
I think this is a valid use case for the framework to disable the
SubstituteBindings
middleware in case of redirect routes... Can't think of any scenario where raw request parameters shouldn't end up in the destination url as-is.The text was updated successfully, but these errors were encountered: