Private statebags and statebag rejections

It would be nice to have a way to send a statebag directly to the entity owner server<->owner. This would allow for additional security as not every client will be aware of the bag unless it’s replicated.

Statebag rejection is also an important measure of security to reject bag changes on the server.

2 Likes

Let me know if I’m missing something here, but entity state-bags already have a write restriction policy, where only the entity owner or the server can change the value of the state-bag.

So how would this increase “security” in any way? I don’t know about any use case where state-bags contain token or any “relevant” data that shouldn’t be read by other clients.

Some cases might want to have even the entity owner not be able to override custom state directly.

… and this (outside of optimization reasons) might be relevant as some sort of ‘state that only the entity owner actually needs to run code’.

This is exactly what I’m looking for. In some cases, it is only necessary for a bag to be received by the owner and nobody else for a case like this.

I assume “private” states or whatever you want to call it would be somewhat bothersome, as you need to sync that state whenever entity owner changes; however it should be relatively simple (I assume) and still quite useful to setup for entities that have a persistent owner (i.e. player states).

Would simplify working with personal player data a lot, without having to setup a bunch of events and exports (adding dependencies).

Really not sure how rejection is intended to work as I know it’s planned, but even just having to do some policies in server.cfg or something would be better than nothing (kind of like using set/setr now). I guess the problem is needing the client to wait for server ack before actually setting the state and triggering change handlers?

5 Likes