I want to make a system in my game where if you get to a specific region (defined by a .touched function in an invisible part), you get to proceed to another stage which will be loaded in. I have tested and managed to stop any exploitation of this by moving the part with a magnitude check.
After this happens, I want to fire a RemoteEvent in order to allow a gui to create new dialogue for the next section. The problem about this is that I think any exploiter can just fire this event and continue to the next stage without actually completing it. I have seen people say that avoiding any vulnerabilities is better than trying to protect the RemoteEvent itself, but both ways I am stumped on what I can do to do anything.
From what you’ve said, it sounds like the client doesn’t control what level they are on, which is not a vulnerability. If the remote isn’t connected on the server and you handle the level logic on the server, this can’t be an issue.
If you handle critical logic on the server and move them to the next level there, basically follow that principle of not trusting the client, you should be fine. Other people were right with what they said; there’s no use securing the remote itself. Exploiters can just bypass it with this:
getconnections(remote.OnClientEvent)[1].Function() --runs your OnClientEvent listener
I don’t think I fully understand what you’re asking, either, can you explain a bit more about where you think the vulnerability is and how an exploiter might go about, well, exploiting it?
sorry for the lack of clarification, but I was planning to make it so that the remoteevent causes the localscript to finish its dialogue, and then that will be the cue for a serverscript to load the next level. I felt like this might leave some holes for the exploiter to fire the serverscript and load the level without doing anything.
When you say “Causes the LocalScript to finish its dialogue”, what if you made it a set time for the dialogue to finish? That way, you could just fire the remote and wait that time length on the server.
Or, you could on the server, only process responses that are expected when you are expecting them with the expected content. This way, the exploiter can’t successfully load the next level without completing the other one first.