#Livewire manipulation

21 messages · Page 1 of 1 (latest)

molten frigate
#

Hello lads,

I've got a quick question.

I'm using the public property:

public $modelId = null

Then in the mount function I do this.

public function mount(Model $model)
{
  $this->authorize('view', $model);
  $this->modelId = $model->id;
}

Whenever I am using the model on a page i use computed properties:

public function getModelProperty()
{
  return Model::find($this->modelId);
}

Then later on when I have for example a update function.

public function update()
{
  $this->authorize('update', $this->model);

  // update the shizzle
}

Just making sure, the public $modelId CANNOT be manipulated trough JS or the browser right?
(The check-sum will make sure of that)

Meaning that everything is authorized correctly in this case?

upper mango
#

If it's public, it's visible to the frontend. If you don't want to send something to front, consider making it private and just make sure you validate that the user is editing resources that belong to them

#

If someone forcefully changes the ID through console, at least make sure that it can only belong to them

molten frigate
# upper mango If it's public, it's visible to the frontend. If you don't want to send somethin...

Thankyou for your reply!

The fact that it is visible is not the problem they can and are allowed to see it!
The thing I am afraid of is if they change it trough console.

livewire.components.componentsById.{key}.data.modelId = 12345

If they do this, and then press the update() button, will $this->model still use the edited $this->modelId (what would be 12345 then after editing it in console)
Or will this ALWAYS result in the hydration error cuz the check-sum is gonna fail!

upper mango
#

You can try it yourself and see:
livewire.components.findComponent(component_id_here).set('modelId', 10)

#

that way you probably could change the ID without triggering the error

#

But if you try to change the component data itself, there should be a checksum error yes

#

I would suggest just either passing a full model to your component or making the ID protected and loading the public model on mount

molten frigate
molten frigate
upper mango
honest hollow
# molten frigate Thankyou for your reply! The fact that it is visible is not the problem they ca...

To expand on this some more, if you try to directly modify the Livewire object like this then Livewire's checksum will fail and throw an error. This is because Livewire can't restore the exact state it was in before any changes/ updates happen.

Where as when you use .set as suggested by @upper mango, the internal state of the component isn't changed. Instead an update is queued, to be applied to the component after it has been hydrated.

Because of this, it means the update runs through all the standard updating/updated lifecycle hooks, which allows you to validate the data (ie ensure the user has access to a resource).

So while you can't stop a user from trying to be malicious and changing the modelId property, you can validate that they have changed it to an ID that they have permission to use and if not throw an authorisation error, therefore not actually being able to access an unauthorised model.

It's basically the same as if the model ID was passed to a standard Laravel controller endpoint. It would need to be authorised.

That's why it's best practice to ensure everything is authorised on the backend, ie: mount method, so ensure user can access the ID, any updates to ensure if the ID has changed that they have access, and also on any public (action) methods like save/delete/etc.

#

Basically don't trust the user. Validate and authorise everything.

molten frigate
# honest hollow To expand on this some more, if you try to directly modify the Livewire object l...

Thankyou for your time!

So if I am reading this correct, looking it: https://laravel-livewire.com/docs/2.x/lifecycle-hooks#class-hooks

I could for example use

public function updatingModelId($value){
 // validate if this ID is valid, if not trow error?
}```

To see if the changed value with ```.set``` is valid?
honest hollow
#

Yep, that's correct, so in there you would put your authorisation and/or validation

molten frigate
#

Thankyou I completely understand it now 🙂 And I also have some applications to change now XD I've been using full page components for a big project lately and I catch a lot, every update,save,etc function is protected but this just seals the deal completly 🙂

honest hollow
#

No worries! Glad it was helpful 🙂

#

And awesome! 😁 I use full page components for everying. No more Laravel controllers for UI

molten frigate
honest hollow
#

Yep exactly!

molten frigate
#

@honest hollow looking back at it now I was just being naive thinking that my public $modelId is any different then a public $name field haha. Should and couldve known that a .set would change it haha.