10 likes
·
2.8K reads
8 comments
Great article.
I thought this is handled automatically via checksum. From livewire documentation v2 (cannot paste the link):
The Checksum The fundamental security underpinning Livewire is a "checksum" that travels along with request/responses and is used to validate that the state from the server hasn't been tampered with in the browser.
Yes, there is a checksum. But that is the point. If you would change the value through the "wire" by using $0.__livewire.$wire.postId = 5 the checksum will be recalculated because this is a legit action because $postId is a public property. Only if you would do something like $0.__livewire.data.postId = 5 the checksum would fail as soon as you click save.
Stef Rouschop got it. Thanks
Wouldn't $this->authorize('update', $post) in the save method prevent you from tampering with posts you're not authorized to update?
Yes it does. That’s why I included it, it’s more like a double check. Depending on the project, the auth policy can differ. In some weird cases, a user could return true to a policy (is in the same team, etc.) and you still do not want them to tamper with the ID. In that case the lock would be helpful. Also, the ID is just an example. For example, you could also lock a variable that contains an action type like ‘create’ or ‘update’. A public variable can be useful for something like this, and you don’t want users to tamper with that.
Makes sense, thanks for the swift reply!
Also, just a heads-up: Livewire 3 will probably use an attribute like #[Locked] for it
Ruben van Erk you’re welcome! Yes, I noticed Caleb was still in doubt how the attribute is going to be. But a find and replace in the code base isn’t that much of a hassle 😉.