Title says it all. I have a coding problem with my game and it looks like I will need to use remote functions for it. I want to know is there a way to use it without hackers being able to yield or cause errors?
2 Likes
Remote functions and events are safe if you use them wisely. Always validate player input and limit access to sensitive features.
4 Likes
How would I prevent server to client to server remote functions from yielding
2 Likes
You can’t stop RemoteFunctions from yielding. You’d need to use RemoteEvents. If you want to make sure it is safe, you could use typeof().
Example:
MyRemote:FireServer(1, 10)
Then:
MyRemote.OnServerEvent:Connect(function(player, number1, number2)
if typeof(number1) ~= "number" then return end
if typeof(number2) ~= "number" then return end
print("Valid arguements!")
end)
This would prevent hackers from forcing code to error in their favour by sending the wrong data type.
Hope this helps!
1 Like
So instead of using a remote function I could use 2 remote events, one that fires to client then inside that it fires to server?
3 Likes
You could just use the same RemoteEvent each time (for two-way communication), but yeah, pretty much. Make sure to always check data types server-side.
Like checking with RemoteEvents, you can check with RemoteFunctions too.
myFunction:InvokeServer("this string gonna cause an error")
Then:
--ive never used a remote function so idk what it is on server invoked
--but you would do:
if typeof(variablePassed) ~= "number" then return false end
Originally the remote function would be to get the humanoidrootpart cframe from the client because on the server it is not exactly accurate. How would I do this with the remote event
Suphi has a video on this:
Client:
local character = --path to character here
local hrp = character:WaitForChild("HumanoidRootPart")
MyRemote:FireServer(hrp.CFrame)
Server:
MyRemote.OnServerEvent:Connect(function(player, frame)
if typeof(frame) ~= "CFrame" then return end
print(frame)
end)
But yeah, I don’t recommend using RemoteFunctions.
Actually, I think that remote functions are safe when it’s the client that make the request, but if the server make the request, exploiters and hackers can make that it won’t return and the server script will wait forever.
So if you want to use remote functions from server request, I advice to use two remote events or one, idk how you can make it with one, but yeah.
Okay, has anyone ever attempted to get the humanoidrootpart cframe from the client because of server delay/inaccuracy?
Like this you can see that when you’re moving, the projectile starts where the humanoidrootpart is on the server, but not on the client which is where you see the player actually is.
Just as long as you have server checks, I think remote event/functions are safe
Let the client tell the server where the HumanoidRootPart’s CFrame is. Just validate the data type server-side.
In the majority of cases RemoteFunctions should only be used to invoke the server. It generally isn’t advised to invoke the client with RemoteFunctions because the client could indefinitely yeild the server. If you’re thinking of invoking the client try and figure out a different approach or way to make what you’re making. Chances are there probably is a better approach that doesn’t involve invoking the client.
In cases where you have to invoke the client and have no other choice make it so the server assumes the client wont ever respond. In other words, make it so the server assumes it be yielded. Also, any data send from the client shouldn’t be trusted so make sure to validate it.
It is worth noting that using RemoteFunctions to invoke the server is considered safe because any data sent from the server shouldn’t have been tampered with. Also, the server wont yeild the client forever unless it has been specifically coded to or there is a bug caused on the developers part.
You could solve this by:
- Sending current client-sided position of character.
- Predicting future character position (simple moveDirection operation on client-sided which is then sent over remote).
Although be careful you need to set arbitrary limit of wiggle-room so that player can’t fire from any position, and you might need to check if player’s desired predicted position is inside-behind wall.
For your usecase, just sending the client-sided position should be fine because remotes are quick like that.
Do you know of any other viable solutions than invoking the client?
Just letting myself into this conversation.
Just have remoteEvent which fires request for the data to specific player and then player sends these data to server. Server then processes these various data. It is that simple.
Simpliest form of this is:
local function foo()
local someRemoteConnection
remote:FireClient(player, "Request")
local function onServerEvent(recievedPlayer, data)
if recievePlayer ~= player then
return
end
--// Call function outside for further processing, or do additional operations with these data here.
someRemoteConnection = someRemoteConnection:Disconnect()
end
someRemoteConnection = remote["OnServerEvent"]:Connect(onServerEvent)
end
Now, this approach has the possibility of implementation with server-sided yielding, meaning no data after some period will be processed just as:
task.delay(yieldTime, function()
someRemoteConnection = someRemoteConnection:Disconnect()
end)
Oh okay when I come back I will see. This looks like a good way to approach it
Does this somehow cause performance issues or anything issues like that?