Enforce whitelist and add command - #3467
Conversation
Wunka
left a comment
Wunka
left a comment
There was a problem hiding this comment.
Thanks for continuing with this!
| const keys = zon.getChild("keys"); | ||
| try conn.user.?.identifyFromKeysAndName(name, keys); | ||
|
|
||
| if (main.server.world.?.settings.whitelistEnabled and !main.server.players.isAllowedToJoin(conn.user.?.newKeyString.?)) { |
There was a problem hiding this comment.
I don't like this. In my mind this can perfectly work in sync with a ban system (blocked = banned)
I would suggest to go in the direction I went with permissions. Instead of returning in isAllowedToJoin a bool return an enum: {allowed, neutral, blocked} neutral would then be the case where you need to look if whitelist is enabled
| .alreadyAllowed => source.sendMessage("#ff0000{s}§#ff0000 is already on the whitelist", .{key}), | ||
| }, | ||
| .block => switch (players.block(key)) { | ||
| .blocked => source.sendMessage("#00ff00Blocked {s}§#00ff00 from connecting", .{key}), |
There was a problem hiding this comment.
If we go by the principle that blocked = ban then I would suggest to also kick the player here
| } | ||
| } | ||
|
|
||
| const KeyString = struct { |
There was a problem hiding this comment.
In general we put these kinds of helper in command.zig I can already imagine there being a command to for example update the key where this would help
|
True, it does make more sense to treat an explicit block as a ban |
2 participants
Enforces the player whitelist during the connection handshake and adds a
/whitelistcommand to manage it.After a connecting player's key is resolved, the server checks
players.isAllowedToJoinwhenworld.settings.whitelistEnabledis set, rejecting the connection witherror.NotWhitelisted.Command syntax:
/whitelist <add/block> <keyType>:<base64Key>or/whitelist <add/block> @<playerIndex>Also removes error logging for
error.NotWhitelistedsince it's expected to reject and already logs the reason right after rejection.Closes #2566