CLI Overhaul

[zulujive]

Summary

Let's face it: the CLI is less than ideal. For one, you can't SSH into it to manage anything remotely, it's just one big if/else statement, and it's incredibly hard to implement automations to make life a little easier. The only way I can do remote management right now is through virtual desktop, which is slow and risks security.

Proposal: redo the CLI and contain it within a directory and add a simple way to interact with the CLI when working outside of the running process.

This shouldn't be too hard considering we have all the code there; we just need to move it around and handle it differently. That way, we can slowly add features like adding roles to the admin panel instead of relying on an ancient and inconvenient system.

This doesn't mean we need to remove the existing syntax, but instead we allow for more ways to interface with the application with custom scripts and automations (like making a cronjob to reload user roles every x minutes).

Honestly, this is long overdue. I highly suggest this to be a major focus in the coming months of development.

Details

First, we should create a directory dedicated to interacting with the application externally. Each file will correspond to a set of jobs, using standardized parameters and syntax. A central file will be the main pointer to these services based on the type requested.

Next, we add an additional file for handling endpoints. Where do we want to allow commands to come from? What kind of authentication are we going to use? That's the idea here: splitting things up and making the application configuration based.

I would suggest that we have a file specifically intended for handling cronjobs. That way, it'll be easier to setup and maintain those automations. I'm thinking this could be a shell script so all cron needs to do is send the parameters to such a script.

In the App.jar file, I suggest we just remove all the if/else mess and route all CLI commands to the central pointer file in the API file. We should be keeping the App.jar file as clean as possible. It should be the smallest and cleanest file, we don't want it to become the app itself.

As always, feedback is appreciated here. I'm not going to advise for a certain approach programmatically, but my hope is that I can give a framework for how I think the application should work.

[BlankParenthesis]

The idea behind a developer management API is not terrible. Such a system might be nice, but I'm not sure how much use it would be. As you mention, most of the tasks which require this level of interaction would be better served as implementations in the admin API. The two most common use cases that come to mind are account login management and role management — I would rather see a focus on that first.

Secondly, I'm not sure what your setup looks like but there are several ways you can interact with pxls console externally with ssh. Notably, screen, tmux, and now piping to stdin via a file with systemd have all been used on the production pxls server to facilitate this without the use of a full virtual desktop.

Separating the server process into a more microservice approach is also something that has been looked at and is desirable, but the CLI input system is by far the least invasive system in this regard and something like the chat service would be a far better candidate to split out in my opinion.

[trwy7]

This may also be great for adding donator roles after a specific donation amount, so it would add the role without intervention. I still have questions on how it would authenticate people, like would it need an API key from console, or would it check if you were logged in with a staff account via your cookie? This seems like a good idea for management though.

[zulujive]

I did actually toy with that idea a bit. The trouble is that most payment and donation systems are very strict about API access for what I hope are obvious reasons. I believe I have a Discord bot for adding donator roles to users automatically, but that’s about as far as that goes.

The issue with Pxls is that it’s in limbo between being a small application and a relatively large application. We have an admin panel, but the functionality is limited, we have a CLI, but again, the functionality is limited and frankly just annoying to work with. If we can lay the groundwork for having a larger application with features typical of one, it’ll make managing things way easier down the line.

The main proposal I’m making is that we abandon what we’ve had to put up with and replace it with a more modern and scalable solution. For example, I could send a POST request to the API to add roles to a specific user. That’s how it should’ve been from the get-go. And the idea here is to simply make a web application work like a web application. The CLI should always be an option, not the only option.

Honestly, my biggest thing right now is adding more advanced user management to Pxls and making site configuration a little more accessible. So let’s just set a goal here: have an endpoint for adding roles to users by the end of January. It’s not the end of it, but we can at least start the process of migrating to a web-based interface instead of relying on a so-so CLI.

The beef I have with Pxls is that it’s only partially a web application. Like yes, it exists primarily on the web, but it’s not typical for a web application to require an interface off the web for basic administration features. Pxls was never particularly beautiful or modern. Honestly, I don’t really care about that, but it’s time we embrace a more standard approach to web applications.

[BlankParenthesis]

Along these lines, pxls-rs and PxlsNetworking may be relevant.

Whether a full rewrite or a major overhaul are the best approaches is debatable, but the desire for a more unified REST-like API is definitely felt.

[zulujive]

Fair enough, could we implement a simple API to allow users with a reload permission to reload the config? This is the main issue: database applications that I've made require me to go into the CLI and reload everything. It'd be nice if we can just have it so you send a GET request to "/reload" and it's handled that way.

[BlankParenthesis]

I think implementing something simple like an endpoint which forwards a text command to the current console could be excused. A full architecture rewrite seems overkill but a simple retrofit like that could be accepted I think. An endpoint accepting a POST request to /console with a command parameter seems simple enough.

[zulujive]

Precisely! Easy to implement and gets the job done so we can build out custom web apps.

[BlankParenthesis]

I might draft something up later today since I'm considering merging PRs anyway. I can't promise it will be merged so quickly but it can at least get the ball rolling.

One possible consideration is the security surface this exposes: I shall see about gating it behind a default-off configuration setting perhaps.

[zulujive]

Ooh, great! Yeah we should make a cli permission given to nobody in the config. It should be an option for the future, not an unused endpoint open to admins.