Indigo Domotics

This is the old Rest Api script (activated from Carbon Copy Cloner to the Indigo Server that a backup process has been started, visible at the control page)

Code: Select all

#!bin/sh

/usr/bin/curl -u User:Password! --digest -X PUT -d value=blue http://192.168.111.11:8176/variables/CCCBackup
/usr/bin/curl -u User:Password! --digest -X PUT -d value=$(date +start@:%d_%m-%H:%M) http://192.168.111.11:8176/variables/CCCBackupDate


How can we convert this to a Local Secret Authentication?

- a new JSON file must be created into the directory?:
/Library/Application Support/Perceptive Automation/Indigo 2023.2/Preferences/secrets.json

- In that JSON file must be the password?


Thanks for the support and patience.

John

This one:

Code: Select all

#!/bin/bash

curl -X POST -H "Authorization: Bearer my-local-secret" -d '{"message":"indigo.variable.updateValue","objectId":1033915322,"parameters":{"value":"blue"}}' http://127.0.0.1:8176/v2/api/command
curl -X POST -H "Authorization: Bearer my-local-secret" -d '{"message":"indigo.variable.updateValue","objectId": 660038,"parameters":{"value":"start@'$TIMESTAMP$(date "+%d-%m-%H:%M:%S")'"}}' http://127.0.0.1:8176/v2/api/command

Gives this error:

Web Server Warning access denied for request /v2/api/command from 127.0.0.1 (token my-l****)
Web Server Warning access denied for request /v2/api/command from 127.0.0.1 (token my-l****)


We made a file: /Library/Application Support/Perceptive Automation/Indigo 2023.2/Preferences/secrets.json
With the content:

Code: Select all

[
    "do-not-use-api-keys"
]

We followed this "Local Secrets" documentation:
https://wiki.indigodomo.com/doku.php?id ... r_settings

In essence, using the phrase "do-not-use-api-keys" tells the server to not allow access using that secret. By specifying that as your only secret, the server is rejecting the request. Change "do-not-use-api-keys" to something else like "abc123def456" and it should work (the second key will never work). Don't forget you need to change it in your curl commands as well. I don't think a server restart should be required after the change. FWIW, if you have this as your local secret.json, it will work with the first key.

Code: Select all

[
    "abc123def456",
    "do-not-use-api-keys"
]

If you specify the second key, the server will block it.

EDIT: added a little more regarding the specific key "do-not-use-api-keys" -- which won't be honored by the server.

Thank you very much for your answer Dave, that is appreciated.

OK, I changed the content of the JSON file to:

Code: Select all

[
    "abc123def456"
]

And the script to:

Code: Select all

#!/bin/bash

curl -X POST -H "Authorization: Bearer abc123def456" -d '{"message":"indigo.variable.updateValue","objectId":1033915322,"parameters":{"value":"blue"}}' http://127.0.0.1:8176/v2/api/command
curl -X POST -H "Authorization: Bearer abc123def456" -d '{"message":"indigo.variable.updateValue","objectId": 660038,"parameters":{"value":"start@'$TIMESTAMP$(date "+%d-%m-%H:%M:%S")'"}}' http://127.0.0.1:8176/v2/api/command

Did also a restart of the Indigo Server.

Then I got this:

Web Server Warning HTTP API v2 POST command received, id: '- no message id -' from '127.0.0.1'
Web Server Warning HTTP API v2 POST command received, id: '- no message id -' from '127.0.0.1'


Any idea?

Thanks for your support.

John

Just to follow up on one thing -- you must restart the server after making changes to the secrets.json file because Indigo reads that when the web server is first started up.

John - just saw your message.

The payloads under the new HTTP API are structured differently than the old API. Please consult this page for the different things it can do.

Thanks for your feedback Dave.

I know there was a change in the API.
(viewtopic.php?f=131&t=26965&hilit=bash)
This script was working well with Indigo 2023.1:

Code: Select all

#!/bin/bash

curl -X POST -H "Authorization: Bearer xxxxxxxxxxxxxxxxxxx -d '{"message":"indigo.variable.updateValue","objectId":1033915322,"parameters":{"value":"blue"}}' http://127.0.0.1:8176/v2/api/command
curl -X POST -H "Authorization: Bearer xxxxxxxxxxxxxxxxxxx" -d '{"message":"indigo.variable.updateValue","objectId": 660038,"parameters":{"value":"start@'$TIMESTAMP$(date "+%d-%m-%H:%M:%S")'"}}' http://127.0.0.1:8176/v2/api/command


But we want to change the API key via the Indigo account, to local secret key

So, I thought that replacing the xxxxx into abc123def456 (from the local JSON file) did the trick but that gave an error.

Those were warnings (not errors) that are alerting you to the fact that the payload didn't include an "id" key. Running this payload against the API silences those warnings:

Code: Select all

{
  "id": "optional-custom-user-message",
  "message": "indigo.variable.updateValue",
  "objectId": 1547222515,
  "parameters": {
    "value": "Some string value"
  }
}

Where as this one will yield a similar warning (no "id" key):

Code: Select all

{
  "message": "indigo.variable.updateValue",
  "objectId": 1547222515,
  "parameters": {
    "value": "Some string value"
  }
}

The underlying variable update probably still worked. Adding an "id" to your payload(s) should get rid of the warnings.

Thanks for the explanation Dave.
The script now indeed works , but I cannot get rid of the error/warning. Sorry, programming is not one of my talents.

Code: Select all

#!/bin/bash

curl -X POST -H "Authorization: Bearer abc123def456" -d '{"id": "optional-custom-user-message","message":"indigo.variable.updateValue","objectId":1033915322,"parameters":{"value":"blue"}}' http://127.0.0.1:8176/v2/api/command
curl -X POST -H "Authorization: Bearer abc123def456" -d '{"id": "optional-custom-user-message","message":"indigo.variable.updateValue","objectId": 660038,"parameters":{"value":"start@'$TIMESTAMP$(date "+%d-%m-%H:%M:%S")'"}}' http://127.0.0.1:8176/v2/api/command


Web Server Warning HTTP API v2 POST command received, id: 'optional-custom-user-message' from '127.0.0.1'
Web Server Warning HTTP API v2 POST command received, id: 'optional-custom-user-message' from '127.0.0.1'


Is that "ID" not good in the script?

I see the confusion now -- that is a warning message to let you know that there was a request to the API. There's always going to be a warning message unless you affirmatively silence them in the Advanced Web Server Settings dialog. That's not generally recommended as there is some security in being notified that there was a connection attempt.

I was referring to the "...id: '- no message id -'..." component of the warning.

Thanks Dave, I disabled the warning option in the Advanced Web Server Settings dialog and it's working smooth now.

I know it is not super super safe, but having these kinds of messages in the log 4 times an hour is not pleasant either.

Case closed, thanks again for your time and patience, you saved our weekend, cheers!

Welcome! Gute Nacht John.

Vielen Dank David!