Level 2
Try running php artisan cache:clear
Apr 5, 2024
10
Level 1
Laravel session not persisted?
Hello!
I'm having a small problem since this morning.
In the web.php file, I defined the following routes:
Route::get("dashboard", "App\Http\Controllers\Pages\DashboardController@show");
Route::post("flights/import", "App\Http\Controllers\FlightController@import");
The FlightController import method looks like this:
public function import(Request $request)
{
return redirect("dashboard")->with("success", "import-starting");
}
And the DashboardController show method looks like this:
public function show()
{
dd(session()->get("success"));
}
The flashed success message does not appear to be available on the DashboardController. Why?
It's weird because I could swear it worked up until this morning. I make some changes to the code but when back to the code pushed yesterday on Git, so it shouldn't have any impact any more. I am running the Laravel app using a custom docker-compose file, and I believe the persistence of the session got broken for some reason right after after I rebuilt the containers this morning.
Did this ever happened to anyone else? Thank you!
EDIT: I also already tried define the session storage as file and database without any change.
Level 1
@enoch91 I already tried with no luck :(
Level 1
By the way, a bit more context might help here: this is a simplified problem of my issue. I actually use Laravel for the backend and Vue for the frontend, with Inertia JS for the communication between the two.
The user has a button in his dashboard to download the import of a sample file (calling the flights/import endpoint) and I would like to display a banner saying that the import started. I then return back with a flashed message and I defined a ShareInertiaData middleware which contains the following:
public function handle($request, $next)
{
Inertia::share([
"flash" => function () {
return [
"success" => session()->get("success"),
"error" => session()->get("error"),
"status" => session()->get("status"),
"data" => session()->get("data")
];
},
]);
}
However the session does not contain the flashed message even though it used to. This middleware is called last in the "web" group, and is called after calling explicitely the StartSession middleware.
protected $middleware = [
// \App\Http\Middleware\TrustHosts::class,
\App\Http\Middleware\TrustProxies::class,
\Illuminate\Http\Middleware\HandleCors::class,
\App\Http\Middleware\PreventRequestsDuringMaintenance::class,
\Illuminate\Foundation\Http\Middleware\ValidatePostSize::class,
\App\Http\Middleware\TrimStrings::class,
\Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class,
\Illuminate\Session\Middleware\StartSession::class
];
protected $middlewareGroups = [
"web" => [
\App\Http\Middleware\EncryptCookies::class,
\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
\Illuminate\Session\Middleware\AuthenticateSession::class,
\Illuminate\View\Middleware\ShareErrorsFromSession::class,
\App\Http\Middleware\VerifyCsrfToken::class,
\Illuminate\Routing\Middleware\SubstituteBindings::class,
\App\Http\Middleware\ShareInertiaData::class
],
];
Level 29
@ced2718 There already exists a middleware named HandleInertiaRequests which contains shared data. Try to add your flash object in the share method of that middleware.
Level 1
@gych I did see that in the documentation and I tried to use it but it didn't change anything. In any case I always used my own middleware and it worked just fine up until yesterday. I really think it's more an issue with Docker since it showed up right after I rebuilt my containers.
Level 29
@ced2718 I doubt that Docker is causing this but you could always try to run the application outside of Docker to be 100% sure
Level 1
It seems that the session is actually persisted (if I do session()->put("test", "test"); within the import method, I do get it back on the other end in the handle method of my middleware).
I guess the flashed message gets erased for some reason between my controller and this middleware.
Level 2
@ced2718 Ensure that the ShareInertiaData middleware is not interfering with the redirection process. It should be placed after any middleware that might modify the response headers or perform redirections.
Level 1
@enoch91 It is indeed placed as the last middleware. It has always been the case and it used to work up until yesterday evening :(
Level 1
Seems that my issue is actually coming from a bug which was introduced in version 3.13.0 of the laravel debugbar. I juste submitted an issue on the package's Github respository.
Please or to participate in this conversation.