Neither. As mentioned, it’s for another API. It’s an example on how to add headers to your HTTP Binding Thing, because your x-token is a header parameter.
google search shows that there should be an URL where you can download the token for a current session ( /action/tokenGet ).
That means you first need to login; then get the token and then use the token in the header for the action that you would like to execute.
So yes every login in the browser also will show a new token.
Thank you, Wolfgang.
So that means, that it’s not possible with the HTTP binding only, but with an additional curl request!?
I will try to get it done.
Am I right assuming, that my browser token does not work with the http binding, because this very token has been initiated by the browser and not the http binding itself?
If so, that would mean, that I need to purely implement it with curl.
Unless the token is accepted because it’s initiated from the same machine (localhost)!?
I am not that familiar with the http binding that I can either say it is possible or it is not possible. If the http binding allows a two step approach then it should be possible - but that I cannot answer.
That is the idea of that token. Nevertheless even if it works the next browser session creates a new token that is to be used and it needs to be transferred to your OH environment.
Yes, as long as the token is tied to the host/IP and not to a session id as well.
Actually running everything with curl does not even need the token.
So I am wondering why the http binding is not able to access the alarmsystem with regular Basic Authentication.
May I ask what “running everything” means ? Do you use multiple, consecutive calls to curl with cookies handed over from one call to the next ? If that is the case could it be that the token is already handled/set by the initial call ?
I mean, that I have separate rules using curl on an executeCommandLine to retrieve information from the alarm system.
The curl call just provides user:passwd@ip-address.