JSONRPC: jamulusserver/setWelcomeMessage request

[rdica]

It was a shot in the dark since a filepath is a string, but a test showed that using this method to change the welcome message ended literally showing /path/to/file as the welcome message instead of its contents, as the -w /path/to/file cli arg does.

While I'm aware I can paste a bunch of html code into the json object, that's unwieldly, especially for the more elaborate welcome messages I've seen out there. It'd be easier to point to a file.

Is it possible for this method to behave as -w option does, or if not, can a new method be added to the api to handle files as welcome message contents?

[ann0see]

Probably yes? @dtinth @Rob-NY know JSON-RPC.

[dtinth]

While possible, I’m not sure about adding support for file handling… I don’t see the need because I think it’d be quite redundant.

I would instead write a script that reads the HTML file, construct a JSON object, and send it to the JSON-RPC server. This gives both convenience and more flexibility, e.g. it’s easy to make it do more than just reading from a file.

For example, my fleet of Jamulus servers have the same welcome message format. Instead of a file, I set up a central server that exposes an endpoint.

Every 10 second, a script fetches https://myserver/Jamuluc-CnC/welcome-message.php?server=<serverId> and uses JSON-RPC to deploy the welcome message to Jamulus server.

I do not recommend manually editing HTML in JSON. I would recommend putting HTML in HTML files and have a script convert it for you.

(Thanks for the tag @ann0see)

[pljones]

Currently whether the parameter is a file or directly contains the text is determined at server start up, not dynamically. Of course, the constructor could be changed to move the code into a method and call that with the argument, so the same method could be called with a value whilst the server is running. As far as I'm aware, the server UI can't enter a filename with the message content: the field is always used as the value directly. Making this change would change that behaviour, too (which is an improvement worth having, in my view).

[Rob-NY]

@rdica - are you saying that your servers would have a pre-populated set of welcome messages accessible within the server’s filesystem and you’re looking for an RPC method to switch among them? Example: Ok, now load the welcome message from /path/to/file2 and use it…

[rdica]

@Rob-NY Interesting thought but no, my thinking was to have a single file, be able to edit it, then reload it without having to restart the server.

[Rob-NY]

So basically an RPC request that forces a re-read of the welcome file specified on the command line? But to the point made by @dtinth, going onto the server and editing the welcome file and then using a REMOTE procedure call to reload it is a somewhat odd workflow. Perhaps I'm just not understanding your workflow correctly -- nevertheless, I'll look into forcing a reload of the same file specified on the command line (not a different file).

[Rob-NY]

Upon server startup, if the welcome message text passed via the command line is determined to be a valid filename, the file is read and its contents used as the message, but the name of the file is not preserved.

I think there are two ways to address this:

If the welcome message passed on the command line is determined to be a file, preserve that filespec so it could easily be reloaded in the future. Would require some logic and and additional class property. It would also require a new RPC call to "reload" a filespec that was already specified.

Alternatively, and maybe better as it addresses multiple use cases (and how I believe @pljones interpreted this): Change the logic of SetWelcomeMessage itself to check if the welcome message being passed to it is a file that exists. This is basically what is done during server startup prior to setting the welcome. The added benefits would be that the existing RPC call (unmodified) could be used to: a) read any file as a welcome message, and b) switch between html messages and file-based messages. Further, (and I need to test this) you could now enter a filespec in the server UI welcome message textbox as well.

So, @rdica, this would address your issue, but you would need to know the name of the file you want to reload via RPC.

I believe there is an inherent security issue here (and with the code as it exists today) that passing a file as a welcome message (via the command line or ultimately via RPC) could expose sensitive information. Ex: -w /etc/passwd I'm sure this must have been raised in the past at some point.

[pljones]

Anyone who can type Jamulus -s -w $(cat /etc/passwd) could do Jamulus -s -w /etc/passwd, really - if you've access to run Jamulus, it's all the same.

Maybe the JSONRPC needs more fine-grained access control...

[Rob-NY]

A proof of concept works fine for command line and RPC. However, when it comes to the server dialog box things get a bit strange. Entering a filespec in the server dialog will, in fact, load that file and new clients will see the file-based welcome. The problem is that the INI (settings) is updated with the actual welcome message, not the filespec, because GetWelcomeMessage() is called when jamulus is exiting. This means that the next time you start the server UI, you will see what was IN the file, not the file name itself.

Fixing this would require some substantial refactoring to the dialog and settings -- so how do folks feel about the filespec feature functioning more like an initial MACRO when entered into the UI?

[pljones]

Personally, I'd rather the value entered was stored in the ini file. I don't remember if the field in the UI supports HTML - if not, it might be nice to add a "Preview" feature to display the value as it'll be rendered in the Chat dialog, loading a file if specified and rendering any HTML (either in the file or in the text box). If we did this, it would mean the ini file then should definitely store what was entered in the UI - not go reading the file.

If I entered ".../path/to/html/dailynews.html" in the text field, I'd mean I want the content of that displayed - not read. It should be something I can set once for Jamulus then update without worrying about having to go into Jamulus and reset it.

It's things like this that show how much love the settings system needs and how much the separation between the component layers could be improved.

[hoffie]

I think we should properly separate the two modes somehow (file to load vs. string to display).

A possible approach:

• Deprecate -w and --welcomemessage in favor of a new --welcomemessagepath and --welcomemessagetext
• Optionally add support for using the path-based approach in the UI (not sure if it's necessary)
• JSON-RPC should also be clear about the difference. setWelcomeMessage could either support two mutually exclusive parameters (text vs. path) or could be split into two methods (setWelcomeMessageText, setWelcomeMessagePath).

Wrt security: The fact that JSON-RPC is bound to localhost by default and is authenticated should limit the exposure. But in general I agree that we must be careful regarding all file based actions.