Edit other configuration files

[stag-enterprises]

In server settings, currently you can edit server.properties and amscript files, but some add-ons require editing other configuration files. On a local instance this isn't too bad; but with a remote headless instance it creates a lot more friction to edit other files. If the current editor could also be extended to allow for users to select arbitrary files to edit, this would be really great.

[macarooni-man]

Hi @stag-enterprises, I'm currently looking into a way to do this. It's not as simple as you might think because the server.properties editor is a custom solution for cross-platform functionality. I'm going to effectively have to make my own text editor/file explorer that is compatible with Telepath to also support cross-platform functionality.

Also to clarify, I won't allow users to edit arbitrary files because that would cause a security risk. But my ideal implementation would be either:

• A full file explorer that can remotely access the remote server folder, and only anything with that folder (a LOT more work)
• an endpoint/local function that can recursively scan for config files and allow you to edit them as needed (preferred)
• With either approach, I would like to create a similar instance of the server.properties editor because Kivy is a lot easier to work with. But it would be limited to editing a single file at a time because the lack of multi-window support in Kivy

[macarooni-man]

Hey @stag-enterprises, I've decided to go with creating a YML editor for now. Can you provide some example mod config files and server config files to test?

[stag-enterprises]

@macarooni-man Sounds good to me. I might also suggest adding a JSON(5) editor too. A lot of mods use JSON, and being able to configure datapacks (which also use JSON) would be handy. Probably falling back to a plaintext mode in case neither of those formats are used should be done too probably.

Here's some config files: https://paste.sr.ht/~stag-enterprises/0e0bd91e4909ee386c1841849ef599747b0ee713

[macarooni-man]

@macarooni-man Sounds good to me. I might also suggest adding a JSON(5) editor too. A lot of mods use JSON, and being able to configure datapacks (which also use JSON) would be handy. Probably falling back to a plaintext mode in case neither of those formats are used should be done too probably.

Here's some config files: https://paste.sr.ht/~stag-enterprises/0e0bd91e4909ee386c1841849ef599747b0ee713

@stag-enterprises Yeah I understand, I'm going to start with a YML editor for now. The thing is I'm very particular about syntax highlighting and functionality, like for example the server.properties editor has key protection and a lot of other really useful features to prevent people from breaking the config and adding efficiency. Due to the way I want it to be designed, it's a LOT of work to make it feature complete since I have to tailor a specific editor to each format.

Thanks for providing the config files!

[macarooni-man]

Testing and tracking this functionality on the dev-editor branch

[stag-enterprises]

Just thought of something that might be important here.

On auto-mcs.com/guides/telepath, it states:

Keep in mind that any action other than authentication will remain in plain text.

Would you consider supporting HTTPS (or any other method of encryption) on the Telepath API? This is more important since editing files remotely means file contents are being sent over Telepath, and some config files might have sensitive info, like API tokens in them.

If you do, I imagine that you would have to generate a X509 certificate for each instance, and on initial Telepath connections supply the certificate to encrypt future requests.

[macarooni-man]

@stag-enterprises the intended solution is to tunnel it yourself, or generally access a secured instance over a VPN.

Despite that, it's a valid point, and I could certainly try to look into implementing the authentication functionality for encypting text based files. The biggest challenge with this approach is the performance overhead, because it would have to encrypt EVERY file. The least common denominator could be an amscript with an API token as you've suggested, but it could also be a config file inside the raw content of an uploaded auto-mcs backup. Since most of the functions that manipulate remote files are either blocking or async, this shouldn't be a huge problem. I am stumped as to how I might implement that other than wrapping the upload/download endpoints with a key exchange, like the login methods. If you have any suggestions from a methodology standpoint I'd love to know your thoughts!

The biggest issue I have with directly implementing HTTPS is that it makes it an order of magnitude more challenging to debug Telepath itself. Since I'm the only one working on this project right now, I don't feel confident in globally implementing a solution like that internally and being able to maintain it effectively. Additionally, HTTPS has overhead due to the encryption in the first place, which is why I wanted to implement it solely for authentication. Telepath is noticeably more responsive when using HTTP from my testing.

With that being said, I would like to have that discussion in another issue. I'd be happy to look into implementing file-only encryption with the current solution like you've suggested, but it likely won't be in this update.

[macarooni-man]

Completed

#121