Well, sorry for any confusion. I didn’t state it that well, i’ll say.
The example I gave was an example of what not to do - that’s why it’s bad code.
From a purely computational point of view, you would have less work to do to achieve the exact same result by sending the reference, because the server can already trust what is on the server, and would therefore not have to worry about checks. This is an objectively better way to do it, as there is absolutely zero possibility that your checks can fail - again, because they don’t exist.
Relying on a client-side UI element for the prices of items is inconvenient, unconventional and inefficient, I don’t know of a single person who would ever do this. The most efficient way to do so is to store items and their required info (stats, prices etc.) in a ModuleScript, as such would allow for the client and server to access the values with ease. They’re always in one place no matter what.
Yes, it works under specific circumstances, but a lot of bad practices do. That example should not be encouraged nor should ever be used, and would actually take much more work to maintain than my previously mentioned ModuleScript approach.
1 Like
Again, I feel you’re missing the point of my posts.
I agree with this, I never said otherwise, but you’re failing to separate the intentionally bad example I gave, and the point I was making
I fully understand your point here, that sending a reference to the server is still a “secure” method in the sense that the client cannot truly edit the value. However, regardless of whether it’s secure or not does not mean it should be encouraged as it can be bad practice. You are, more or less, encouraging it from the context of your posts. (If that’s not the case, then that’s my bad)
I understand that you were just working with the example, but instead of doing so you should’ve pointed out the flaws in said example and provided a much better alternative, just a bit of future advice.
Regardless, we’re derailing the thread a little too much. Let’s leave it here, I think both of our points have been made more than known.
I’ve done this in a number of my responses, please read through all my replies not just the ones addressed to you.
Whenever the client interacts with the server verify that the request is legitimate by ensuring the client has met all of the conditions to be able to make said request. For example, if a player requests to buy an item in-game like a sword or a health potion, check if the client has the money on the client and if they do, send the request to the server. Now, on the server, verify the client has enough currency to buy the items and if they do, grant the request and give the client their merchandise but if they don’t, then (assuming your conditions were checked properly on the client) the client probably illegally requested to buy the item which is when you punish the client i.e banning or reverting their stats.
Not all requests will be easy to verify but if you practice that logic with your work, you’ll be writing a lot more secure code.
Another way you can approach this is to specifically target the tools or methods the exploiters use to exploit your game for example GUIs (Dex Explorer) and the developer console. But just to be clear, this is a very cat and mouse game and it’s very prone to backfiring if you don’t know what you’re doing so if you aren’t too familiar with exploits, you should probably stick to the first approach.