Potential Livewire 419 Error Situation Being Caused by Laravel Views Scripts Directive

[orware]

@Gustavinho,

Hi Gustavo,

I was running into a 419 error (like you described here: https://github.com/livewire/livewire/pull/1146) today after including the Laravel Views package on my end yesterday.

I was thinking it was more of a general Livewire issue, but as I dug into looking into the problem, which I've documented over here: https://github.com/livewire/livewire/issues/2822

It seems like the issue might have more to do with how the @laravelViewsScripts() directive includes the Livewire JS onto the page.

In my webapp, it ends up embedding the the Livewire JS directly in the cached view file for my base.blade.php file.

This means that the livewire_token value is also being embedded into the cache directly (and since the base.blade.php file isn't changing, the cache isn't being refreshed at all, so the token becomes stale relatively quickly).

I don't know if anyone else has reported a similar problem, but I understand that I can use:

@livewireScripts
@laravelViewsScripts(laravel-views)

as an alternative, which helps to avoid the issue since the @livewireScripts directive doesn't embed the Livewire JS directly into the page (instead, it is simply transformed into a call to this function: <?php echo \Livewire\Livewire::scripts(); ?> which I believe allows for the livewire_token to be correctly created dynamically the way it's supposed to).

So I just wanted to share/report the problem in case there is an improvement you can implement on your end that would help avoid the issue.

I'm looking forward to trying out your package (I hadn't gotten that far into doing that yesterday...I had simply added your include directives and I ran into this 419 issue today and have been trying to figure it out for most of the morning here so I hope this info is helpful :-).

[Gustavinho]

Hi @orware

Thanks so much for raising this, this is the first time that someone is reporting this behavior but I think it makes sense, let me get this straight, so basically what the @laravelViewsScripts() directive is doing is that it is embedding the JS directly on the HTML, while the @livewireScripts directive is embedding PHP code to call \Livewire\Livewire::scripts(), is that correct?

Indeed @laravelViewsScripts() is internally executing Livewire::scripts() and sending the result to the browser, which are the Livewire JS files, I never imagined that could lead to issues with cached files, but now that you brought that up it makes sense.

As a workaround yes, you can use

@livewireScripts
@laravelViewsScripts(laravel-views)

as you said before, but the @laravelViewsScripts should be able to replicate the behavior of @livewireScripts, definitely there is room for improvements on that side

[orware]

@Gustavinho,

Your understanding of the issue is correct :-).

Hopefully changing things to be similar to the default Laravel behavior/output of \Livewire\Livewire::scripts() isn't too difficult, but I definitely think that will help others to avoid the issue I was scratching my head about this morning when I came back to my desk and encountered that 419 error/issue :-).

[Gustavinho]

Thanks a lot again for raising this, I will definitely change the behavior of that directive, please let me know I you're having any issues with the package, I'll be glad to hear. your feedback in order to make improvements

[orware]

Will do, thanks Gustavo!

[Gustavinho]

By any chance are you using the csrf token on the headers?

[orware]

I'm not sure if it's exactly what you're asking about, but earlier when I was starting to look into the issue I did see that there was a X-CSRF-TOKEN header in the request here on my end (along with a XSRF-TOKEN value being set in the Cookie header).

I did see other issues mentioning the 419 error for Livewire that sort of mentioned excluding some of these types of values potentially, but none of those seemed fully correct to me so when I dug into the issue a bit more that's where I uncovered what I noticed about the livewire_token value being embedded in the base.blade.php cache file on my end (which led me to the @laravelViewsScripts situation).

[Gustavinho]

I ask for this meta tag <meta name="csrf-token" content="{{ csrf_token() }}"> on your headers, but I will change it anyway to replicate the behavior of the @livewireScripts directive

[orware]

Gotcha, I'm not seeing that particular <meta> element on my end in the HTML output on the page, although it does seem like that X-CSRF-TOKEN in the request header I am seeing may be occurring (perhaps Livewire is handling that for us automatically?).

I noticed both mentioned in this area: https://laravel.com/docs/8.x/csrf#csrf-x-csrf-token