on-prem / jidoteki-admin-api Goto Github PK

The NTP server should be managed by the API as well. This can be added as an optional setting to settings/index.l

Related to #1 - If the token can be set using newtoken= then there should be a separate API endpoint for this as well.

Rebooting to confirm whether storage options are correct is painful. It would be preferable if remote storage endpoints can be 1) discovered, 2) tested.

Accidentally discovered a small bug in the /admin/services endpoint which prevents parsing from continuing when the script output contains a capital T.

https://github.com/unscramble/jidoteki-admin-api/blob/master/api/v1/admin/services/index.l#L9

(till T) should be replaced with (till).

The appliance's unique build information should be returned by the API.

It can be implemented similarly to the version API endpoint.

The certificate upload occurs as a background task. It should be possible to retrieve the status as well as the log. The API call to api/v1/admin/certs only returns the log at the moment.

The /settings endpoint should accept a {'wifi':[]} block to configure settings for wireless access points. It should accept an array of settings, and spit them back out in JSON and in a format parseable by on-prem/jidoteki-admin#10 scripts.

When making a call to /api/v1/admin/update/log , the API crashes because the file doesn't exist.

A check should ensure the file exists before trying to parse/display it.

When JIDO_API_PORT environment variable is set, the http server cannot start:

$ JIDO_API_PORT=8888 ./run.l
HTTP listening on port: 8888
[app.l:26] !? (port *Port)
"8888" -- Bad argument

This happens because *JIDO_API_PORT is a string rather than a number, when the environment variable is loaded.

The disk usage graph should display available space VS used space correctly.

The current display is strange.

The API should allow an authenticated user to upload their own TLS certs:

• public certificate
• private certificate
• CA root certificate

This can then be merged into a single enterprise.pem file.

If an appliance is built without NFS support, then it shouldn't be available as an option in the API/UI.

There should be a configuration file which defines which storage options are available, so the API/UI can present only those options.

To avoid sending the authentication token across the wire, we want to implement a hmac based verification. The token will be a shared secret between the client and API:

• Choose a suitable HMAC hashing algorithm (sha1, sha256..)
• Concatenate the HTTP Method, URL, and token to generate the hash
• Validate the hash based on the request method, URL and token
• Remove simple token-based authentication
• Ensure old authentication scheme still works, to allow backwards compatibility with older clients

Upon login, the Admin UI requires the auth token to be between 8 and 64 characters, but the Admin API doesn't have this restriction when setting/changing the token.

The best fix is to modify the API to only allow tokens between 8 and 64, but this breaks backwards compatibility. It would also lock-out anyone who's already using a shorter token with the API.

The proper fix is to not perform validation of the auth token's length (in the UI)... or to allow any non-zero absolute value.

Certificate validation will return an error message (http-msg 400) if no public/private key is sent, but will continue processing and still end up calling (certs-update), because (http-msg 400) isn't final.

Luckily the backend scripts in Jidoteki Admin have safeguards and will return 1 (and fail) if there's no public/private key file, but this should still be corrected.

The bug can be found in the code here. It's a bit subtle, but essentially on L50 after calling (http-msg 400), the next condition (if Private.. will be called. Doh. Not what we expected.. 🤕 🌴

The following API calls should return a body:

• POST /api/v1/admin/update
• POST /api/v1/admin/settings

.. at least to know the request is being processed.

The ability to toggle a service on/off via the API would be beneficial in many situations.

An endpoint POST /services for updating the toggle status of designated system services.

This feature should provide the option to enable/disable designated system services, which are specific to the appliance (generic in the API). The settings should be stored in services.json as well as flag files on the system.

Setting the token through the query parameter is clever but goes against proper REST etiquette.

This should be set as a form parameter similar to [email protected].. for example: newtoken=mynewtoken.

By default, the API is accessible in cleartext on port 8080 (configurable), on all IPs.

Ideas

• Add the ability to specify which IP to listen on
• Add the ability to listen on a UNIX domain socket

The API documentation should provide more detailed information on usage, parameters and responses.

To ensure only specific clients can use the API, we want to implement client/server certificates. This should be the default, but will be optional in the event the clients are always trusted (ex: private LAN).

These changes are specific to stunnel and its default config (verify = 3 ?):

• Optionally load stunnel-strict.conf
• Add self-signed server root CA certificate
• Validate the client certificate using the root CA certificate
• Reject requests from invalid clients

Currently the GET /api/v1/admin/update endpoint responds with a qualitative status, success, failed, running. Is it possible to get a percentage progress based on the packages or steps that are contained in the update package?

The current version of the API will only run on a 64-bit OS because it requires PicoLisp 64-bit and performs a few (native) calls.

Some changes are necessary to let it run on a 32-bit OS which doesn't support (native):

• Replace all (json~) calls with a conditional (symbols 'json)
• Use external json executable or internal @lib/json.l to parse/create a JSON string
• Adjust tests

When no API token is set (missing api.token), the HMAC authentication can be bypassed by generating an SHA256 HMAC with an empty string.

The API should always validate whether the api.token exists, and return NIL if it doesn't.

The GET /update status endpoint returns a JSON response containing status and log. Parsing the log for a human friendly message is not ideal and error prone.

I propose adding a message property in the JSON response that contains a descriptive message. This is important when a failed status is received. There are several cases where an update would fail such as already up to date, failed to decrypt update package, incorrect checksum of update package, etc. Each case should produce a unique error message to indicate the cause of failure.

Alternatively a code, statusCode or errorCode property could be added which would indicate a failure reason. The consumer of the API can write their own messages from the status code.

In either case, responding to an upgrade failure will become easier.

The following API endpoints should return a proper HTTP response when there's an error. At the moment they just crash silently:

• GET /update
• GET /certs
• GET /settings
• GET /storage