Progress Bar

[plucky verge]

I've successfully created a progress bar by adding an event that listens for when the property object "CurrentValue" changes, but one thing I'm worry about is the fact that exploiters might be able access this information.

I currently have a simple profile store set up and I want to be able to sync it with the storage system in the future.

Should I move this system to the server side and connect it via a remote event?

Questions:
Am I misunderstanding anything?
When is the right time to worry about the security, now or later?
Are exploiters able to access everything that is replicated to the user?
Lets say I add an attribute instead of a property to the progress bar. Is that attribute limited to the server or client side?
Any feed backs on what you are seeing so far?

[slender charm]

** You are now Level 2! **

[dapper ledge]

1. I would recommend using a remote event rather than physical values either way
2. all remote events/values are susceptible to exploiters. All you ccan do is make sure they cant use that information maliciously and that they can't manually change it (use sanity checks)

[plucky verge]

1. Thank you, if I were use of a remote event would I detect changes and be firing from the server side to client to update gui?

2. So in my system, exploiters would be able to use and change the information?

3. Can you explain what are sanity checks?

[dapper ledge]

1. yes.
2. they can only change it if they can send a remote event to the server to change it.
3. it's checks on the server that check if what the client is asking is valid.

For example,

if you have a server side script that listens to a remote to update a value:

local Remote = ...
Remote.OnClientEvent:Connect(function(Player,NewValue)
Data[Player] = NewValue
end)

In that case, the exploiter can just spam whatever value he wants and it will update. Sanity checks basically prevent that. Sanity checks make sure that there can ONLY be change if it's allowed/normal. What you could do is:

local Remote = ...
Remote.OnClientEvent:Connect(function(Player,NewValue)
if not Player:HasRankInGroup(12345,"Admin") then return end
Data[Player] = NewValue
end)

that check now made it so that the value can only be changed if the player has an admin rank in a group. This is just one of many ways to do a sanity check. Now, if the exploiter doesn't have the right rank, he can't change the value. Sanity checks can come in many shapes and forms. One common sanity check is if the client wants to damage someone, the server checks that the player is actually close to the other player and not across the map.

It's to prevent the server from just blindly trusting the client.

I would look up a tutorial, they can probably explain it better than I can

[plucky verge]

Nah this is a great explanation, thanks!

[plucky verge]

Hi Unceen,

Do you perhaps know the answer to the questions:

1. When is the right time to worry about the security, now or later?
2. Lets say I add an attribute instead of a property to the progress bar. Is that attribute limited to the server or client side?

[dapper ledge]

1. I would do it as you're scripting it. You could do it later but it's almost always to better to do it as soon as possible
2. if you're using :SetAttribute() then both the client and server can see it (if you did it on the server) if you used set attribute on the client, only the client can see it and not the server.