Filament•12mo ago

Notifications are only displayed by Refresh

I just have a filament v3 behavior where I am running out of ideas. Everything is running but the notifications (in page builder) are only displayed after reloading. Everything works locally, only on the server. Does anyone have an idea? The actions otherwise work perfectly, only the notifications only appear after reloading the page. Since it is not a direct code problem, I have put it here. I don‘t use the database notifications.

Solution:

Okay, so the problem is that the RFC allows an empty header but not the WAF and therefore the header "X-Livewire" was not passed through. That was the problem, we are now enforcing this and now it works.

Jump to solution

31 Replies

dennis_deOP•12mo ago

The response of the components in the dispatches also contains "close-modal" as an example but not the "notificationsSent" 😄 super wired I have already emptied all caches and synchronized .env variables to rule out all simple errors.

Lara Zeus•12mo ago

can you show the code for sending the notification? as toeknee mentioned did you add ->send()?

dennis_deOP•12mo ago

Saw the question. I'm just mobile at the moment and need to check. However, it doesn't only occur with my own notifications, but already with homemade actions. Edit actions, Password Broker, etc. @Lara Zeus I am now back at my PC. As already mentioned, it also occurs with filament classes/services such as the Password Broker. But with my own notifications (which work locally) I used the following code:

Notification::make()
                ->title('Message')
                ->success()
                ->send();

Notification::make()
                ->title('Message')
                ->success()
                ->send();

Lara Zeus•12mo ago

if it's everywhere, I guess there is something missing from the setup! this in the panel right? not custom pages any console erros

dennis_deOP•12mo ago

no custom pages, panel builder, right no console errors In the XHR response, the "dispatches" of the "components" also contains "close-modal", for example, but not "notificationsSent".

dennis_deOP•12mo ago

local:

dennis_deOP•12mo ago

Remote:

DrByte•12mo ago

Did the notifications "ever" work on the production site? (ie: did this start after some "change"/upgrade/etc?)

dennis_deOP•12mo ago

Exactly the same functions on the server and locally, same endpoints. This is the first time we have rolled it out productively. I must admit that I've never experienced anything like it. I've never had these problems in productive environments with Filament v3. What irritates me so much is that when I reload the page, the notification appears. But it does not come back in the initial request. So it's not that she won't be fired at all, but that it simply feels too late. To be on the safe side, I have already switched to "sync" as the driver, changed the cache driver and session driver and also emptied all caches. View, Event, Config, Routes Cache...

DrByte•12mo ago

Ya, it's puzzling

Lara Zeus•12mo ago

you're useing broadcast?

dennis_deOP•12mo ago

I have also checked the versions (Composer/npm packages).

DrByte•12mo ago

but not "notificationsSent"

seems like this is an important clue though .... I wonder on what conditions it fires vs doesn't fire

dennis_deOP•12mo ago

No, neither locally nor remotely. On the production server as well as locally:

BROADCAST_DRIVER=log

BROADCAST_DRIVER=log

dennis_deOP•12mo ago

This is also the Laravel default. (https://github.com/laravel/laravel/blob/10.x/.env.example#L18)

GitHub

laravel/.env.example at 10.x · laravel/laravel

Laravel is a web application framework with expressive, elegant syntax. We’ve already laid the foundation for your next big idea — freeing you to create without sweating the small things. - laravel...

dennis_deOP•12mo ago

config/filament.php:

dennis_deOP•12mo ago

Broadcasting in filament is not enabled

Lara Zeus•12mo ago

far fetch but you not published the views?! 🙂 dose @livewire('notifications') exist?

dennis_deOP•12mo ago

I use the Page Builder, not Custom TALL. In other words, the views from the Filament V3 vendor. And it contradicts the fact that the notifications appear after the refresh. Or does it? I'm really at the end of my tether. 😄

Lara Zeus•12mo ago

this is what the send fn do

session()->push(
            'filament.notifications',
            $this->toArray(),
        );

session()->push(
            'filament.notifications',
            $this->toArray(),
        );

some thing related I guess any Middleware could affect this?!

dennis_deOP•12mo ago

The tip about the middleware is not so bad. I'll take a look at it. I'm still wondering why it works locally and not productively, but that's another clue I can look at, as we really do have a few custom middlewares.

DrByte•12mo ago

Agreed on that point.

dennis_deOP•12mo ago

However, it does not delete the session, as it appears during the refresh. We actually have middlewares that intervene in the sessions, but only delete individual keys under certain conditions.

DrByte•12mo ago

With notifications appearing after page-refresh, it confirms that the Session is working (but it obviously is for other reasons too, such as login etc). And it confirms that they're "firing" (as in they're being generated). So, that leaves either whatever should be pushing them to the page ... isn't, or whatever should "listen and display them" in real-time, isn't listening.

dennis_deOP•12mo ago

First of all, thank you very much for taking on this problem and trying to provide such active support. This is not a matter of course. Thank you! 🙏 I have now restored the normal (default) web middlewares and in the panel provider there are no other than the default filament v3. No improvement. 😦 I will now go through everything again at my leisure and then, if I still haven't found it, examine the core further and try to narrow down the error. 😄 I'm not giving up. 😄 When I observe my browser, I see a difference that I execute 3-4 requests locally with a save, in the production environment it is only 2. Hmm. So the NotificationsServiceProvider is loaded as normal. I have now tried to find out something in the filament core, unfortunately without success. I'm going to sleep for now and will try again tomorrow. I just spent another 2 hours trying to debug the whole thing and unfortunately got nowhere. Does anyone else have an idea? 🙂

Lara Zeus•12mo ago

did you test it in another places? like create dummy resource or other another page just to trigger the Notifications this is really confusing 🫤

TiBiBa•12mo ago

I had a similar issue and it was solved adding missing middleware in Kernel.php If I recall correctly adding these solved the issue:

\App\Http\Middleware\setSessionDomain::class,
\App\Http\Middleware\EncryptCookies::class,        \Illuminate\Session\Middleware\StartSession::class,

\App\Http\Middleware\setSessionDomain::class,
\App\Http\Middleware\EncryptCookies::class,        \Illuminate\Session\Middleware\StartSession::class,

Are these all present in your used middleware?

dennis_deOP•12mo ago

->middleware([
                EncryptCookies::class,
                AddQueuedCookiesToResponse::class,
                StartSession::class,
                AuthenticateSession::class,
                ShareErrorsFromSession::class,
                VerifyCsrfToken::class,
                SubstituteBindings::class,
                DisableBladeIconComponents::class,
                DispatchServingFilamentEvent::class,
                CheckImpersonate::class,
            ])

->middleware([
                EncryptCookies::class,
                AddQueuedCookiesToResponse::class,
                StartSession::class,
                AuthenticateSession::class,
                ShareErrorsFromSession::class,
                VerifyCsrfToken::class,
                SubstituteBindings::class,
                DisableBladeIconComponents::class,
                DispatchServingFilamentEvent::class,
                CheckImpersonate::class,
            ])

setSessionDomain? 😮 I've never heard that one before. And in the Kernel.php: web group:

\App\Http\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \App\Http\Middleware\VerifyCsrfToken::class,
            \Illuminate\Routing\Middleware\SubstituteBindings::class,

\App\Http\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \App\Http\Middleware\VerifyCsrfToken::class,
            \Illuminate\Routing\Middleware\SubstituteBindings::class,

$middleware:

\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,

\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,

It occurs in every resource, as already mentioned, but also in Password Broker etc. Okay, if I start "php artisan serve" on the server, it works. We were able to narrow down that it works without a WAF & load balancer, i.e. directly to the nginx. We are now working with the IT service provider to find out what has been modified in the request to cause the error to occur. The setup is: WAF -> Load Balancer -> Webserver -> PHP-FPM We were able to narrow down that it is definitely the WAF...

Lara Zeus•12mo ago

we have WAF too I hope we wont ran into these issues when deploy to prod

Solution

dennis_de•12mo ago

dennis_deOP•12mo ago

In other words, an empty header in the case of Livewire "X-Livewire: " is not transmitted. Super nasty edge case and a great learning experience. We have now built a WAF rule that turns "X-Livewire: " into "X-Livewire: true". According to Livewire's code (which we have examined), it only checks whether a header exists, not what the value is.

Gaming

Programming

Notifications are only displayed by Refresh