Hey. I want to know if a script should check player cash on client side or server side. For example: a player picks an option in the UI to buy 5 apples for 20 dollars. Would it be more secure to check if a player has 5 apples before firing a remote event to give the player an apple, or check while the remote event is firing.
(or both?)
(Removed my earlier message because I didn’t quite think about it)
You should check on the server for it because exploiters can manipulate client-sided values. Although Synapse and some other exploit software are offline there are still others.
You could also check on the client but the cash amt shouldn’t be stored on the GUI or anything directly client-sided. A more efficient way would be to have values stored in ReplicatedStorage.
Or, you could just check on both.
Server Side, always Server Side.
The Server is more Secure place than the Client will ever be, as the Client can be manipulated by Exploiters, When checking on the Server, you should always assume the Data the Client has as false, also known as Sanity Checks
Sorry I didn’t really think about this lol. But maybe just make PlayerStats in replicatedstorage or another location so that it can’t be heavily manipulated.
you shouldn’t check on the client, because the client can just change their amount of dollars. although you can put it there for safe measures (for skids), then have the server check that the player actually has 20 dollars.
ok so what I get from this is that you should check on client side to avoid spamming the event and then check on server side to see if they actually have the amt (thanks guys)
No, just Server Slide, its a lot Safer than the Client, and like what I said before:
Checking on the client can be useful for providing the user immediate feedback, instead of having to wait for the server to come back and tell the client “no, you can’t do that.” Of course, client-side checks should never be relied on for security.
couldnt exploiters easily change their cash value on their clientside without the server being aware?
Yes, but if you have a server-side check, the only thing the exploiter is doing is messing with themselves.
the client can only see what the exploiter changes, the server cant see what the client changes, therefore the server is retaining the original money value the exploiter legitmately earned
With important Data, you shouldn’t check the Client, Its safer to just check the Server for stuff like this, which if handled properly, would gaurantee their true amount.
That would be a good thing, the Client has no say in what they can buy or not.
ik but like you said about the immidiate feedback: wouldn’t you just be giving them false information, like them supposed to only be showed that they cant do it but they add more cash to their client side so they wont be able to see it?
now that i think about theres not much of a difference
It depends on whether it replicates to the server or not. The client could change something, but the server may not receive that change.
If the cash value is in the character model, then it would replicate, as the client has “network ownership” over their character.
If it is in the player object in the Players service, then it would not replicate.
(Correct me if I’m wrong)
I actually 100% agree with what @Pokemoncraft5290 said. For a more friendly user interface, it’s actually recommended you have checks on the client (for effects/instant feedback) as well as checks on the server (for verification/security).
Look at the difference in each workflow:
Client + Server Check:
Player1 clicks purchase button → Client checks if he has the right amount → if player does → fire remote with the name of the item the player is trying to purchase → Do verification checks on the server → Give item → if they DON’T have enough → provide instant feedback (such as a UI saying “Sorry you don’t have enough cash”) → don’t make an unesscary remote call.
VS
Server Check Only
Player1 Clicks purchase button → Fires remote to server (even if they don’t have enough) → server checks amount → if player has enough give → give item etc → BUT if the player doesn’t have enough → then fire the client to inform them. → You run into latency problems where if the player is laggy enough, he may not receive the info for a good couple of seconds. Imagine a user spam-clicking a UI thinking it’s not working just for his request to come in couple seconds later telling him he doesn’t have enough cash yet.
Method one would not only limit network calls (for the average player who ISN’T exploiting) but it also provides instant feedback regardless of latency. If an exploiter decides to ignore the client check. Well, nothing happens because the server check verifies everything. Most top games actually use a combination of client checks + server verification to give the best user experience. We aren’t trusting the client → we are just doing simple calculations to provide simple effects. Most games already have the players cash/stats easily accessible on the client and put them textLabals for the player to see. We are simply just using said values for basic user experience needs.
You are missing the fact that when you check the Server with both Client and Server, latency will still occur when you are verifying on the Server, so its still not going to do much when you do this.
However yeah, maybe that could work if you use it properly.
Correction. Latency will occur when the server gives the item BUT when the client-side checks if the player does or doesn’t have enough. It can instantly give feedback regardless of ping. Go to almost any top game → try and like download some random game or something so your ping is horrible lol → then click on their UI and try to make an interaction → if the UI instantly responds with “you are missing such and such” → they have a client-side check (they most likely have a server-side check for security) → otherwise its purely a client-server-client interaction.
You have to understand that we aren’t doing client checks for security. It’s purely for responsiveness/effects. It’s highly encouraged to use both (client and server)for the best user feedback.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.