Darkdawg started a new conversation+100 XP
3mos ago
Hey!
I created a SFC for a Flux:select, using the Modelable attribute. However, when triggering a save from the parent component the value isn't grabbed from the child. I'm using wire:model without any modifiers.
Changing to wire:model.live works, but I don't want the redundant requests.
This works with the old class based components, so I'm wondering if this is a bug?
Darkdawg liked a comment+100 XP
4mos ago
@Darkdawg thats pretty interesting!
Darkdawg wrote a comment+100 XP
4mos ago
Love Livewire!
I'm running Livewire in a somewhat weird way these days. I store the full page response as plain html pages, stripping out CSRF tokens and anything dynamic using middlewares and such. On page load I inject them again using fetch requests and cookies.
Livewire is still there, I just use the manual Livewire.start() approach to ensure CSRF tokens are injected before booting it. Works great, and I can now serve the whole app through a CDN like Cloudflare, giving me instant response times. Any Livewire update request just goes straight back to the server as usual. Just gotta make sure the cache gets busted on updates, but that's simple enough.
Darkdawg wrote a reply+100 XP
5mos ago
I think you're missing my point.
A page becomes dynamic (in the caching sense) only when the HTML output varies per user or per request. Livewire itself doesn't magically make a page dynamic - it's the session-bound CSRF token injected into the HTML that does. Is a page dynamic just because it has a <form>?
Yes, Livewire requires PHP to handle its update requests, but that happens after the page is loaded. My point is strictly about the initial HTML response. That response could theoretically be fully cacheable if it didn't include per-user data like the CSRF token. All subsequent Livewire requests would still hit Laravel normally.
My theory is that the CSRF token is unnecessary for public, non-auth pages, because there is nothing to protect against. Without the token the page can be fully cached, and you still get to keep all the wonderful things Livewire gives you. The SPA navigation and the server-driven reactive forms for example.
As far as I know, there's nothing a malicious site could achieve through a public Livewire component that it couldn't already do by just requesting the same public endpoint directly. Since there's no authenticated state involved, CSRF doesn't actually block any meaningful attack here.
I may be missing something about how Livewire internally depends on CSRF, so that's what I'm trying to understand better.
Darkdawg wrote a reply+100 XP
5mos ago
Sorry for resurrecting a 7-month-old thread, but I was hoping you or someone could clarify a few things.
I'm experimenting with Livewire components on public, non-auth pages (same HTML for all users). From what I understand, these routes don't really benefit much from CSRF protection, right? My impression is that CSRF is mainly meant to prevent unwanted actions on behalf of an authenticated user, so for pages that don't have any user-specific state or actions, I'm not sure what it would be protecting against.
My goal is to fully cache these pages as static .html. The problem is that Livewire injects a CSRF token at the end of the <body>, and because the token is session-specific, it breaks the cache. If I strip the token out of the cached page, Livewire stops working whenever it tries to make updates.
I'm fairly sure the CSRF token is unnecessary for completely public pages with no user-specific state - but I might be wrong. Would it be a bad idea to disable CSRF verification for these specific routes so that Livewire can work without injecting a per-user token?
Any insight would be appreciated!