Skip to content

Conversation

@Slendy
Copy link

@Slendy Slendy commented Sep 21, 2025

Closes #92

  • This PR adds commands for turning the whitelist on and off, adding and removing players from the whitelist, and viewing which players are on the whitelist.
  • Whitelisted players are not persisted and are cleared on a restart.
  • There is a hard limit of 8 players on the whitelist, at which point other players must be manually removed to make room for new players.
  • If a player is not whitelisted, they are disconnected when the client sends the login start packet and see 'Disconnected' on their game client.

This PR also reworks the command system to make it easier to add new commands in the future.

The memory impact of this change is 128 bytes for storing the 8 whitelisted players and another byte for toggling the whitelist on and off.

Tested on a ESP32-WROOM-32 dev board.

@StupidRepo
Copy link
Contributor

StupidRepo commented Sep 21, 2025

This might add a bit more to the memory consumption, or might not even be possible/hard to do, and also belong in it's own PR, but perhaps an even better way of command handling would be to:

  1. store a list of commands
  2. make a function that can 'register' new commands (e.g. registerCommand(name, help message, pointer to function))
  3. then make a 'dynamic' command handler which can work out the args sent through by the player and pass them through to the specified command's function.

Idk, maybe this is too 'involved' for, what is supposed to be, a simple barebones server, but it is a suggestion nonetheless

@Haider982
Copy link

In my opinion, add a config to enable commands and whitelisting.
You might want to also add handling for two players connecting with the same username.

Copy link
Owner

@p2r3 p2r3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At a glance, seems fine, just a few nitpicks. Haven't yet tested in-game, I hope I'll be able to get around to that soon.

// #define WHITELIST

#ifdef WHITELIST
#define MAX_WHITELISTED_PLAYERS 8
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like WHITELIST is redundant if we've already got a whitelist limit. You could just check if MAX_WHITELISTED_PLAYERS is greater than 0.

src/commands.c Outdated
Comment on lines 8 to 30
if (message_len <= 1) {
goto cleanup;
}

char* command = strtok((char *)recv_buffer, " ");
#ifdef WHITELIST
if (!strcmp(command, "!whitelist")) {
handleWhitelistCommand(player);
return;
}
#endif
if (!strcmp((char *) command, "!msg")) {
handleMessageCommand(player);
return;
}
if (!strcmp((char *) command, "!help")) {
handleHelpCommand(player);
return;
}

cleanup:
// Handle fall-through case
sc_systemChat(player->client_fd, "§7Unknown command. Type !help for help.", 40);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be cleaner with an if-else chain? The early exits don't make too much sense if the conditions are all the same size and don't nest any further. Would also eliminate the need for a goto label.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add spaces after if tokens, before opening bracket.

src/procedures.c Outdated
}

#ifdef WHITELIST
// Returns whether the username is on the server whitelist and if so, the index
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment seems to be inaccurate?

@p2r3
Copy link
Owner

p2r3 commented Sep 23, 2025

@Haider982

In my opinion, add a config to enable commands and whitelisting.

Commands on their own are fairly lightweight. Whitelisting is already behind a define here.

You might want to also add handling for two players connecting with the same username.

That's outside the scope of this issue/pull request.

@siaeyy
Copy link

siaeyy commented Sep 24, 2025

I think we should store properties like whitelist, and in a file other than world data.
It might be a little confusing due to features being disabled/enabled during compilation, but i think it's worth it.

@p2r3
Copy link
Owner

p2r3 commented Sep 24, 2025

@siaeyy If you're suggesting we store configuration options in a file, I strongly disagree. The target platform is embedded systems, many of which do not have filesystems, and certainly not efficient ones.

@siaeyy
Copy link

siaeyy commented Sep 24, 2025

@siaeyy If you're suggesting we store configuration options in a file, I strongly disagree. The target platform is embedded systems, many of which do not have filesystems, and certainly not efficient ones.

With a more advanced beef dump protocol we could also provide support to those platforms but yeah I changed my mind, probably doesnt worth it :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Feature request: Whitelist to keep out scrapers

5 participants