HTTP Binding - handshake_failure


I am using the http binding for some things succesfully.
For the integration of my alarm system I struggle with th authentication (I guess).

In the past I read about (and used) the pre-emptive authentication, but all changes I made did not work.

This works fine and returns a json response:

curl 'admin:xxx@'

My http thing uses this base URL:

I tried this with all three different authentication types.

However, as soon as I create a channel with the state extension:


I get the errors:

2022-04-19 13:36:52.310 [TRACE] [ttp.internal.http.RefreshingUrlCache] - Requesting refresh (retry=false) from '' with timeout 3000ms
2022-04-19 13:36:52.311 [TRACE] [ttp.internal.http.RefreshingUrlCache] - Sending to '': Method = {GET}, Headers = {Accept-Encoding: gzip, User-Agent: Jetty/9.4.43.v20210629}, Content = {null}
2022-04-19 13:36:52.328 [TRACE] [p.internal.http.HttpResponseListener] - Received from '': Code = {0}, Headers = null, Content = {null}
2022-04-19 13:36:52.329 [WARN ] [p.internal.http.HttpResponseListener] - Requesting '' (method='GET', content='null') failed: Received fatal alert: handshake_failure

I also have tested the option Ignore SSL Errors

I just found this on github, so it seems that I need to have the x-token mentioned there.
I have found this on my system, but don’t know how to use this with the http binding.
GitHub - lkn94/Lupusec-Connector: Connector for the Lupusec XT1 Plus

You’ll need to add it as a header parameter. See this example for another API:

Thank you for your response, @hafniumzinc

But is the x-token the APILEY or APISECRET?
(sorry for this potentially dumb question)

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.

So you would have:


within your header parameters.

Thank you, but the same error is still in place.
On the developer view of my browser its name is X-Token, so I tried this as well - without a change.

And it seems that the x-token changes whenever the session of my browser is expired.

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.