public $user : data of object and related objects visible for user about megaphone

[pjkellar]

PR #21 will address the concerns brought up in this issue. @mikebarlow what do you think?

[mikebarlow]

Hey, so yeah I think @axelzuzek concern is that the user model is visible when you inspect the internal API calls that Livewire performs. So for example from the Megaphone demo, when I run a mark as read command, here is a screenshot from the payload, you can see the serialized user model with ID exposed.

Thanks for the PR, I'll take a look in the next few days. My initial thought had been to remove the public $user and try and do something with $request->user() as I think the user session should be available within Livewire requests. That way we can remove the need for passing the serialized model or even a "notifiable_id" so there should be no issues with user model data being visible in the main request payload.

[pjkellar]

request()->user() is what's being used to set the public notifiable_id property right now, so really we could just drop the public property all together and just use request user in the markAsRead function... I'll make a change to to PR and test in the morning. 👍🏻

[axelzuzek]

Hey Mike, just updated the component and it works flawless. Thx a lot!

[pjkellar]

megaphone/src/Livewire/Megaphone.php

Line 11 in e0eb259

public $user;

currently $user is a public variable and the user-model with all related models is serialized as json and visible for the user client side. This can be a major security issue. As far as I see $user is not used in the components templates so could you please change this to

class Megaphone extends Component

{

    private $user;

...

this would solve the problem.

thx

Can you give an example or screenshot of this in practice? I cannot see anything on my front end for this when rendering the livewire component.

Often I see comments on posts with people bringing up this complaint and 9/10 times it's because they have barryvdh/laravel-debugbar installed and they're seeing the requests from that and mistaking that for the live wire request.

[pjkellar]

Another thing to note here as per the Livewire 2.0 docs:

Note: For this to work, you need to have a validation entry in the $rules property for any model attributes you want to bind to. Otherwise, an error will be thrown.

Since there is nothing bound to $user there will be no actual data passed.

The reason that it cannot be made private or protected is because of this:

protected and private properties DO NOT persist between Livewire updates. In general, you should avoid using them for storing state.
You should also note that while null data type is Javascript-friendly, public properties set to null DO NOT persist between Livewire updates.

So after we trigger a markAsRead() we need to reload the announcements for the user and if user is set to protected or private it will be null and the loadAnnouncements() will return an empty collection.

[pjkellar]

I've updated the PR with the suggestions from this conversation. Let me know what you think.

[axelzuzek]

any news here?

[mikebarlow]

Hey, sorry real life got in the way of getting this done.

Just finished up the readme changes and merged in now as 1.2.0