Console commands via plug-in

    A Proposal which hopefully should not require extensive changes and should mostly leverage existing code.


    A way to issue a console command from a script; it could be a method of the Plugin class (or whatever you think appropriate) taking a string with the console command to execute (and possibly a Player object, as some console commands apply to the issuing player) and forwarding the command string to the console interpreter.


    The goal is to support commands which are not possible (yet?) via the regular framework and, more in general, commands which could be automated to simplify the life of server owners/admins.


    The implementation may be rather bare bones: just a boolean as return value (did/didn't get through), no error report, no particular validation, etc...; it may be already qualified as temporary and not supported in the future, etc...


    It is a kind of a hack, I know, but it could save the day in some cases...

    Indeed that would be a hack which is why I highly doubt if we will be given the power to pass a console command through an api as an actual string. That could create a vulnerability if someone was to find a way to exploit the console itself. Rather, each command function will need to be available in the API with its own method.

    Quote from zfoxfire

    Indeed that would be a hack which is why I highly doubt if we will be given the power to pass a console command through an api as an actual string. That could create a vulnerability if someone was to find a way to exploit the console itself. Rather, each command function will need to be available in the API with its own method.

    Indeed! Having all commands available as proper plug-in methods would be the target to aim at. But, if this is going to take some time, a temporary solution could be useful.


    If console commands were discovered to have a security hole, this would be a problem with the console in the first place, as anyone has access to it, while only server owners can install plug-ins.

    Console commands work this way: There is a set of prepared commands (i.e. "SetTime", "Kick", "Ban" etc., every command has an ID), and every command expects a various amount of arguments ("SetTime" just the hours and minutes, "Ban" the target player, duration and reason etc).
    When the player enters a command, the input will be checked (check plausibility, permission etc) and "converted" into an actual command on the clientside and send to the server (i.e. instead of sending something like "goto..." to the server, just a single ID which describes the "TeleportPlayerToPosition" command will be send). Of course the server also does some plausibility checks and also checks the permissions, and if everything is fine, the command will be executed.
    There are also several "synonyms" on the clientside (teleporting - for example - can be done by typing "goto", "setpos", "setposition", "teleport"), but the server does not know anything about these synonyms. It just accepts a valid command ID (one of the predefined commands).


    Having some behaviour like a real console in the API is a little bit complicated, e.g. a method like Plugin.executeCommand(player, "setplayergroup red51 noob");. To make sure it behaves exactly as the ingame console, it would be necessary to send the command to the clientside, let the client console process the command, and send it to the server accordingly, which is a little bit awkward :S


    Actually it would be better to give access to the predefined set of commands. Maybe an enumeration holding these commands. The function could look like Plugin.executeCommand(Player, Command, String...);, so for example: Plugin.executeCommand(player, Command.SetTime, "9", "30"); //change time to 9:30 a.m
    Downside of this approach is the fact that you have to make sure to use the correct arguments :/
    Maybe it also makes sense to move this method to the player, since the server always expects a player to execute a command (would look like player.executeCommand(Command.SetTime, "9", "30"); then). Is this something you're looking for?


    What do you mean exactly with "The goal is to support commands which are not possible"?

    I think Miwware meant that as a temporary solution to give us console access quickly that it would be easy to implement something like Plugin.executeCommand even while it is possibly less secure.
    In the long run, seems like player.executeCommand approach would be best. The call to the API should also trigger a check to see what permissions that user has.

    It's not less secure, a plugin can at least cause no harm this way. It's just a little bit awkward ^^
    And it may be spooky for the player, since it would be handled as a regular command input. If the API sends an invalid command, the player will see the "Command not found" output in the console (if the API sends several invalid commands to the player, the player may be confused about all the "Command not found" outputs, or even all the "ghost" confirmation outputs).


    But if this feature is required, we can implement it of course :) I just thought the approach with the enumeration (I've mentioned at the end of the post) might be more suitable (it would be the same effort to implement it).

    Personally I'd rather just wait for the "proper" implementation as I'd assume it would give us ways of error handling than simply dumping stderr to the console but hey, it's quick and easy and won't take long to implement. :-D Now perhaps I am overthinking this but... regardless of implementation, if the command was to fail, would it be useful for the method to return whatever expected object and an exit code ? I handle exit codes at work all the time in my scripts (making use of both stdout and stderr). I am rusty on Java but it looks like there to pass multiple objects as an array using Pair or HashMap but I've never done such before so I leave the implementation details to your best judgement: http://stackoverflow.com/quest…lues-from-a-java-function

    I took some time to think again on this point. I was probably a bit too excited about the novelty! Thinking again, practically all the cases I can think of where this 'trick' would be useful can be dealt with in way or another via 'regular' API calls (existent or 'coming soon').


    There are possibly (probably?) cases not coming to my mind right now, but we will cross that bridge when we arrive at it.


    It seemed a clever -- albeit hacky -- way to speed up plug-in development but, after the discussion and the suggestion posted by @red51 in other threads, it looks possibly not so urgent.


    Sorry for the noise! M.

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!

Create Account Login