Handling 419 for authenticated users #1989
-
Hello, I have problem with handling 419 error for authenticated users. Consider these routes: Route::get('/profile/edit', [ProfileController::class, 'edit'])->name('profile.edit');
Route::patch('/profile', [ProfileController::class, 'update'])->name('profile.update'); Then in my app.php: ->withExceptions(function (Exceptions $exceptions) {
$exceptions->respond(function (Response $response) {
if ($response->getStatusCode() === 419) {
return back()->with([
'expired' => true,
]);
}
return $response;
}); This is slightly modified from the docs. This works great when user is unauthenticated and trying to login for example. The "expired" gets flashed and I can handle it in Vue, no problem. Problem occurs when user is authenticated, and they for example update their profile and CSRF is expired. PATCH request is sent to /profile, and this returns 419, which causes redirect back() in our handler. At this point, instead of the app continuing working normally and handling the flashed "expired", following error occurs:
So it seems that Inertia tries to re-send the PATCH request to profile/edit route and causing error. If I don't add this exception code to the app.php, the 419 expired modal is shown normally and works without problems. I would like to flash expired to the Vue, same way as for the unauthenticated user. Am I missing something? I am using Laravel 11 / Breeze / Inertia. Tried with APP_ENV set to development and production. Thanks! Edit. After testing with fresh installation, and with these routes: Route::get('/profile', [ProfileController::class, 'edit'])->name('profile.edit');
Route::patch('/profile', [ProfileController::class, 'update'])->name('profile.update'); It is not breaking anymore but it is not working correctly. The flashed "expired" is not flashed until refresh and console gives this errors: PATCH http://app.test/profile net::ERR_TOO_MANY_REDIRECTS |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
This is because it's sending back a 302 response, the follow-up request is made by the browser, and a 302 means the browser would use the same protocol that was used for the initial request. Usually Inertia intervenes at the backend, by changing it to a 303 response, telling the browser the follow-up should be performed using GET. However, because there is an exception, Inertia's middleware doesn't run. So an easy solution would be to return a 303 response instead of a 302. |
Beta Was this translation helpful? Give feedback.
This is because it's sending back a 302 response, the follow-up request is made by the browser, and a 302 means the browser would use the same protocol that was used for the initial request. Usually Inertia intervenes at the backend, by changing it to a 303 response, telling the browser the follow-up should be performed using GET. However, because there is an exception, Inertia's middleware doesn't run. So an easy solution would be to return a 303 response instead of a 302.