Package com.ultikits.ultitools.abstracts.command.validation.validators

Class PermissionValidator

java.lang.Object
com.ultikits.ultitools.abstracts.command.validation.validators.PermissionValidator
All Implemented Interfaces:
CommandValidator
public class PermissionValidator extends Object implements CommandValidator
Validates that the command sender has the required permission. Supports both class-level and method-level permission requirements.

Which senders actually reach the class-level check (#383, corrected #413). CommandManager.registerCommandDirect calls command.setPermission(permission) with the value from @CmdExecutor, so Paper filters the command out of the command tree of any player who lacks it and answers with a parse error before onCommand is invoked at all. Measured across 22 permission-gated commands on a real 1.21.4 server: a deop'd player received Unknown or incomplete command every time and never this validator's message, while an op'd player received real output for the same commands -- the control proving they were registered and working.

The class-level branch is therefore reached by:

  • the console, which always satisfies the Bukkit-level check, and
  • a player who already holds the class-level permission -- the Bukkit-level filter above only rejects a player who lacks the permission before onCommand ever runs; a player who holds it is not filtered, reaches onCommand normally, and is still evaluated by this branch, where it trivially passes.
A player lacking the class-level permission never reaches this branch at all -- not because this validator would refuse them, but because the Bukkit-level filter above answers first. An earlier revision of this javadoc said the console was the only sender that reached this branch; that was wrong, and the error was easy to miss because a permitted player passing trivially looks, from the outside, indistinguishable from a player who was never asked.

Method-level permissions declared on @CmdMapping are not registered with Bukkit, so those branches run for every sender, players included, normally.

The Bukkit-level filter itself is deliberate and is not a defect to be fixed by deleting this branch or by dropping the Bukkit registration. Hiding a command a player cannot use is standard Minecraft behaviour and avoids disclosing that the command exists; the branch still governs the console, and still governs any player who does hold the permission. What was wrong before 6.3.0 was only that nothing said a permitted player was among the senders reached here. Removing setPermission so an unpermitted player could see the class-level branch's message too would make every permission-gated command visible in every player's tab completion -- a product decision, not a bug fix, and one for the maintainer rather than this class.

Since:
6.2.0
Version:
2.0.0
Author:
wisdomme

  • Field Details

    • ORDER

      private static final int ORDER
      See Also:

    • basePermission

      private final String basePermission

    • requireOp

      private final boolean requireOp

  • Constructor Details

    • PermissionValidator

      public PermissionValidator()
      Creates a permission validator with no base permission requirement.

    • PermissionValidator

      public PermissionValidator(String permission, boolean requireOp)
      Creates a permission validator with the specified permission.
      Parameters:
      permission - the required permission
      requireOp - whether OP is required

  • Method Details