Handling Eloquent Query Builder Serialization Securely Between Components
I'm building a Kanban board package with Filament and Livewire. My architecture has a Filament Page that creates an Eloquent query builder which is passed to a Kanban adapter, and then the adapter is passed to a Livewire component.
However, I'm hitting both serialization and security roadblocks: when Livewire attempts to hydrate/dehydrate the component state, it can't serialize the Eloquent query builder inside my adapter. Additionally, I'm concerned about securely handling database queries across component boundaries.
I've considered:
1. A registry pattern with server-side cache storage (most secure but adds complexity)
2. Custom serialization of query parameters (concerned about exposing query structure)
3. Stateless API-like approach with Alpine.js (better security boundaries)
4. Rebuilding queries on each request (potential for query parameter manipulation)
What's the recommended Livewire approach for securely handling non-serializable query builders when working across components? How do you balance security (not exposing database structure or query constraints to clients) with practical component design?
9 Replies
Maybe a custom synthesizer? https://livewire.laravel.com/docs/synthesizers
Laravel
Synthesizers | Laravel
A full-stack framework for Laravel that takes the pain out of building dynamic UIs.
I'm concerned about security. I set the base query on the Filament page (getSubject method), but then I need to use it across different requests in the KanbanBoard Livewire component.
Hmm, maybe computed or renderless?
What exactly is the security concern?
I think on this case end user can modify the input params.
Task::query()->where('user_id', auth()->id)Like, is there ever a case where any interaction would have a different user? Would they even see things on their board that they don’t have permission to modify?
I would think the board would be scoped to the user and honor the policies as part of the query.
I could certainly be thinking about it wrong though.
The issue with synthesizers is they would serialize query information to the client, including:
1. Query constraints like
user_id = 1 visible in browser dev tools
2. Database structure and business logic exposure
I'm uncomfortable exposing this data client-side.
While policies would still protect data access, I prefer not revealing our filtering logic at all.
Beyond security, serializing complex queries is often problematic:
Size concerns: Large queries with many joins/constraints create bloated payloads
Compatibility issues: Custom query macros, custom query packages, closures, or scopes often can't be properly serializedCan you use the #locked attribute? That way even if exported to the front end it can’t be modified? Definitely a tough one.
So even if user is exposed livewire won’t let it be changed.
But it would have to be a property and not part of the query results. Maybe that doesn’t help.
Sorry I’m not being more helpful. Just trying to think through it all. 🥸
@awcodes Thank you very much for the suggestions!
The Locked attribute is definitely helpful for regular properties, but unfortunately doesn't solve the entire issue with query builders since the concern is both exposure of sensitive query details (even if they can't be modified) and serialization of complex queries.
I appreciate you thinking through this with me! Your suggestions about policies and different approaches have given me some good perspectives on tackling this problem.
Glad to help in some way.