Open wassmas opened 2 months ago
Dont quite understand what you are trying to say. You can set the 4th parameter of setElementData to false if you dont want to sync it from server to client or client to server. And for checking to see if client update elementdata without permission, you could easily build your own system. Check if the client is allowed to change elementdata of key X, if not revert it and take actions. An example can be found here: https://github.com/multitheftauto/mtasa-resources/blob/master/%5Badmin%5D/security/players.lua#L9
Dont quite understand what you are trying to say. You can set the 4th parameter of setElementData to false if you dont want to sync it from server to client or client to server. And for checking to see if client update elementdata without permission, you could easily build your own system. Check if the client is allowed to change elementdata of key X, if not revert it and take actions. An example can be found here: https://github.com/multitheftauto/mtasa-resources/blob/master/%5Badmin%5D/security/players.lua#L9
And when client set element data not synchronized (only client side) can't be detected by server
Dont quite understand what you are trying to say. You can set the 4th parameter of setElementData to false if you dont want to sync it from server to client or client to server. And for checking to see if client update elementdata without permission, you could easily build your own system. Check if the client is allowed to change elementdata of key X, if not revert it and take actions. An example can be found here: https://github.com/multitheftauto/mtasa-resources/blob/master/%5Badmin%5D/security/players.lua#L9
And when client set element data not synchronized (only client side) can't be detected by server
Thats a bad design idea if you trust client in that regard without background checks by server. What youre proposing wont fix the "issue" as the hackers would simply bypass the lua code checking for integrity anyway. You should follow the rule of not trusting the client and validating data sent by client on server.
What happens in the client can't be trusted ever
onElementDataChange
defines client
variable. Are you looking for it?
Is your feature request related to a problem? Please describe.
Cheaters can exploit the lack of synchronization checks in the onElementDataChange event, making it hard to differentiate between legitimate and manipulated data changes.
Describe the solution you'd like
Add a synchronize parameter to onElementDataChange to indicate if the change was synchronized or local. This would help identify and prevent cheating
Describe alternatives you've considered
No response
Additional context
This feature would enhance server security by providing a reliable method to detect suspicious element data changes.
Security Policy