The important difference between a Request and a Demand (and how it relates to Roblox)

Resources Community Tutorials
#1

This post concerns scripters, however, it may be interesting or useful to understand from another perspective, even if you don’t script; or you’re at all familiar with RemoteFunctions, RemoteEvents, BindableFunctions or BindableEvents.

Let’s start with the definitions of the two words, request and demand:

What's a request?

  • “an act of asking politely or formally for something.”
  • “to ask as a favor or privilege”
  • “the act or an instance of asking for something”

What's a demand?

  • “something that someone insists upon having”
  • “something necessary, indispensable, or unavoidable”
  • “to have as a requirement”

How does this relate to Roblox?

You might be wondering; how does this relate to scripting, especially to Events and Functions?

Well, in any kind of web-based service, there is communication between the client and the server. In these communications, it’s generally agreed that these communications should be treated as requests. The problem is, and this doesn’t just apply on Roblox, many people treat them as demands.

It’s understandable, as when you use events within scripts, you treat them as demands, and when you use BindableEvents and BindableFunctions you treat them (as they should be treated) as demands. When people started using the RemoteEvent and RemoteFunction system, they brought over that same practice as previously.

Okay... and?

Well, when you treat client to server requests as demands (the keyword there being ‘requests’), you create massive holes in your game’s security. RemoteEvent and RemoteFunction calls from client to server should always be treated as requests, not demands.

Here’s an example in dialog form:

what not to do
Client: Kill these players
Server: Kills Players

what to do
Client: Hey, would you mind killing these players for me?
Server: Why do you want to kill those players, are you able to kill those players and are you allowed to kill those players?
Client: sowwy im not actually allowed pls no kic-
Server: Kicks player

tl:dr treat remoteevents and remotefunction calls as requests and not demands, or you might get lots of exploity bois

32 Likes
#2

TL;DR : Never trust the client. Ever. Assume EVERY player that plays the game is a script kiddie from V3rmillion.

12 Likes
#3

Although this is correct it’s been said so many times I think it goes over some people’s heads. This post is useful as it provides a practical and understandable application of that rule and why it needs to be stuck to.

1 Like
#4

Horrible assumption. While most people are, if you go around with that sort of mindset you’re going to let the ones who know what they’re doing sweep your system off its feet.

1 Like
#5

Incorrect. Using this mindset can save your system from being swept by exploiters. If you validate any incoming client requests, they have no way of exploiting it, save for hacking the server itself which is not going to happen unless roblox itself has a security gap somewhere.

1 Like
#6

This is right.

This will make your system ultimately fail.

1 Like
#7

I fail to see how this would make the system fail.

3 Likes
#8

Assuming everyone exploiting the game is someone with minimal knowledge of what they are doing gives a false sense of security for the developer which may lead to small holes that don’t look like much until they are made full use of.
You should always assume that all input from the client has been spoofed, but you shouldn’t assume that every client might not spoof it in a meaningful way.
Basically, if you’re inviting people to get around whatever you’re doing by making assumptions then someone is bound to do so.

1 Like
#9

If you’re using proper client validation, this won’t be a problem. By assuming every request is an exploiter:

  • Giving random arguments to the request in a random order
  • Requesting to do an impossible action (e.g. kill everyone in the server or buy an item without enough currency)
  • etc.

You can therefore prevent gaps that are commonly overlooked by assuming any request is exploited.

1 Like
#10

You should definitely program your game like you have extreme trust issues. If the client isn’t unable to do an action that it normally shouldn’t be allowed to do, then it shouldn’t be allowed to do that action. This method alone will increase the security of your game by a huge margin.

3 Likes
#11

What @ANSI_C means is that you shouldn’t assume all players as V3RMILLION script kiddies, but instead assume them as very experienced exploiters who can create an entire exploit geared towards your game if they want to.

1 Like
#12

Yeah that’s what I was trying to imply.

I just called them “script kiddies” because I have a very negative look on exploiters.

#13

Then that’s just not proper usage of the terms. When referring to them you can opt to simply say “exploiters” to avoid ambiguity.

1 Like
#14

I always assume all the players are going to be exploiters x’D

#15

The point is really that it’s actually very easy to keep your game secure, I personally find that it’s actually a lot nicer to make code which uses RemoteEvents and RemoteFunctions properly and securely than to not. It’s so much more structured and can actually often be more efficient for the client (for example kicking a player on the server but just showing a list of players on the client, then all you need to do is check if the player is allowed to kick other players)

1 Like