I know about multiline and I’m using json=1 when doing API calls using HTTP GET, but I would like to rely on SSH keys rather so wanting to get JSON from the command line.
I had a look at the code. The JSON library is this file:
The list-users command program is here:
In there command line options are received, and I don’t see json=1 in there.
I supposed if one could include or remotely call the JSON::PP library arbitrarily from the list-users program it might work.
I see one challenge that a remote API might be some kind of HTTP stream and the entry point will have to look different. This maybe be a relevant line:
# convert_remote_format(&output, exit-status, command, &in, [format])
# Converts output from some API command to JSON or XML format
sub convert_remote_format
{
my ($out, $ex, $cmd, $in, $format) = @_;
Thanks so much @Jamie for the reply. We’re automating a number of our servers and
one of our automations allows end-user administrators to see how much disk space their mailbox users are using.
This automation reads the output from the list-users program and the extracts home_byte_quota_used.
To do it via the remote API means that we send the URL in this format:
https://server.example.com:10000/virtual-server/remote.cgi?program=list-users&domain=example.com&multiline&json=1 with HTTP basic authentication on the HTTP Get commands.
The problem is to get basic Auth to work, we need to store root credentials in our management program in unencrypted format. This seems like a huge security risk. I haven’t figured out if encrypting the credentials is possible on the HTTP Auth calls and I doubt it is.
So what would be a lot more ideal would be to use key based authentication and SSH calls that then remotely executes the programs. The programs currently output a type of text indenting format and it would be hard to rewrite JSON wrappers for those, especially if this has already been accommodated for the remote API.
Technically you could create another “webmin user” with access to the “Virtualmin Virtual Servers” permission, therefore not exposing your “root” password.
I’ve done this a few times in the past, allowing me to setup a sort of “API Key” type model where the username and password was something like: