Thoughts on command hiding plugins

Blog
20 Dec 2024, 17:06
Staff

I want to share some of my thoughts on plugins that hide commands. In short: I'm not a fan of these plugins for a few reasons and they often cause issues with my plugins and my users.

What am I talking about specifically?

I'm talking about plugins that offer functionality to "hide" and "disable" commands from being used by other users. These plugins usually offer a configuration file to allow-list specific commands for all users except server administrators. The plugin will then take this list, and for all other commands on the server:

  • Listen to the command execution event and cancel the event if the base command executed does not
  • Listen to the TAB complete event at a high priority and remove any non-allow-listed commands
  • Some will also carry out packet-level filtering to strip this stuff away, or directly modify the command map
  • Hide the /plugins command and disable TAB completion on it (essentially hiding the plugins list), as well as other system commands (e.g. /version)

Examples of popular plugins I'm talking about (no disrespect to these authors, by the way):

  • Plugin Hide
  • Plugin Hide Pro
  • Pro Anti Tab

Also, I'd like to note I'm not talking about Fabric mods that do similar things here. I don't have an issue with these, as global mod configuration support doesn't really exist on the Fabric server-side mod platform and usually these mods don't cause issues due to design style differences with how Fabric mods register commands typically (without namespace backing, unlike Spigot).

Why people like these plugins

Before I explain why I'm not fond of these plugins, first some reasons why I think people do like them:

  1. These plugins provide one single place where admins can specify what commands people want to be allowed to execute.
  2. Server owners are often very adamant about players not knowing what plugins are installed on their server, either to prevent players searching the names of installed plugins to hunt for exploits, or just as a means of preventing other server owners from copying the functional aesthetic of their server.
  3. A subtle, but important thing: These plugins strip away all the noise from the main command TAB completion list by filtering out all namespace-backed commands from this list.
  4. It's not exactly clear how admins are supposed to be able to disable certain commands. As a server owner, chances are you have in mind a list of things you want people to be able to do, and permission plugins convolute this by asking owners to first understand the concept of permission nodes, then input a list of permission nodes that deny/grant permission to use commands as necessary (instead of just grant).

Why I dislike these plugins

These plugins are designed with a few expectations in mind that cause me issues.

  1. These plugins don't account for command conflicts correctly.
    • Multiple plugins can define the same command name. To avoid this causing a problem, when commands are registered to the command map, Spigot also registers a "namespace-backed" version of the command.
    • For example, when HuskHomes registers /home , the command /huskhomes:home will also be registered.
    • Both the namespace-backed command and the standard command perform the same function, but in the event another plugin (e.g. Essentials) also registers a /home command after HuskHomes does in the server's plugin load order, only HuskHomes' version of /home will be triggered when that command is used. Thanks to namespace-backing, Essentials' command will still be accessible via /essentials:home.
    • My plugin, HuskHomes, happens to utilize interactive chat events, to let you click button links in chat to perform or suggest commands (e.g. clicking on the name of a home will execute the home command to teleport you to it). This is achieved by setting the run command event to /huskhomes:home (name)
    • The problem is, when someone adds /home to the list of "allowed commands" on a command hiding plugin, the other plugin's command isn't available. Server owners almost always don't know about namespace backing, and this immediately causes a problem where clickable chat links don't work.
    • The solution then is to add /huskhomes:home to the command hiding plugin's allow list. But this presents another problem: /huskhomes:home will start appearing in players' TAB list, which isn't what owners want.
    • The workaround for this problem is that I allow for the link-executed command to be changed in the locales files of my plugins (so they could change it to execute /home instead of /huskhomes:home, but this is an annoying hurdle to overcome.. and what if the server owner decides to install another plugin providing that command?
    • Furthermore: These plugins often just don't work properly with Spigot's commands.yml alias definition system: https://docs.papermc.io/paper/reference/bukkit-commands-configuration. This system lets owners define command aliases, which can override the default "primary alias" for commands (e.g. you can map /huskhomes:home to /home, forcing HuskHomes to be the primary plugin to handle the /home command).
  2. These plugins usually don't work at all/very well with Brigadier commands
    • Brigadier is a command library developed by Mojang, and the one actually used by Minecraft. It's possible to register Brigadier commands through various libraries, including the Paper API directly as of newer game versions.
    • The problem is since these plugins are usually designed to work with preventing actions the Bukkit command map, and fail to correctly handle the rich TAB completion and command syntax processing provided by Brigadier.
    • This also affects plugins which use the Commodore library to offer rich TAB completion with Bukkit command map execution handling.
  3. These plugins often break the functionality of command blocks/data packs. You shouldn't be using command blocks/data packs on plugin-enabled servers for performance reasons, but these plugins can cause your command blocks to break.
  4. LuckPerms offers far greater control and flexibility over command functionality on a per-group basis, and permission nodes exist for all commands (including Vanilla Minecraft commands, system commands, and /plugin)
    • To address one specific use case: Hiding the list of plugins on your server. This is a valid use case in terms of aesthetics, but it's important to remember security is only as good as your server's weakest link. Don't rely on plugins that hide information from players for security; be thorough with the plugin selections you make, and avoid unknown and outdated plugins that may introduce gaps in your server's security.
  5. Spigot offers a simple toggle to disable namespace-backed command TAB suggestions, while still keeping them registered to allow for command conflict handling with interactive chat event-based menus.

My recommendations for server owners

The following setup will achieve essentially everything that server owners want to achieve with command hiding plugins. Key things you need to know:

  • Spigot provides a send-namespaced option to disable sending namespace-backed commands in TAB, while still allowing their use. This prevents advertising the list of installed plugins to users.
  • There exist permissions to easily disable the built-in commands of Minecraft and Bukkit, to prevent users from being able to view your plugin list or execute unneeded server commands.

My recommendations are as follows:

Closing thoughts

Those are my thoughts & recommendations. I'd like to close with a few remarks:

  • As a community, I wonder if there's better ways we can present this information to end users to make basic server configuration easier, and introduce the concept of permission nodes to novice server owners.
    • Perhaps the LuckPerms-Web project could look at implementing a UX to make this easier for end users - e.g., add an interface where users can provide a list of commands they want, and LuckPerms will look at plugin.yml files/the command map to attempt to automatically add a list of command nodes the user likely wants?
  • Paper needs merge this pull request which adds better functionality for resolving command conflicts. This topic is another can of worms, but it's a pain that at the minute the primary command alias used when multiple commands are registered by plugins is determined by whichever plugin Spigot loads first.
  • Paper plugins will make Brigadier-based commands in plugins more common, which will cause these command hiding plugins to work less effectively. Paper plugins' load order changes also make the previous point about primary aliases a greater issue.