[remoteopenhab] Add in Username and Password to Connect Through OpenhabCloud

[lsafelix75]

Please include additional credential parameters to the Bridge so that the binding can connect to remote openhab via openhabcloud.

Suggestion is given on https://community.openhab.org/t/remote-openhab-binding-access-rest-via-openhabcloud/116239/6

I appreciate you can review it and include this feature to the binding. Cheers

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/remote-openhab-binding-access-rest-via-openhabcloud/116239/8

[lolodomo]

Your solution is apparently not working, I got a code 401 (Unauthorized):

14:01:05.295 [OH-safeCall-1] DEBUG o.o.b.r.i.h.RemoteopenhabBridgeHandler:166 - REST URL = https://myopenhab.org:443/rest
14:01:05.296 [-thingHandler-1] DEBUG o.o.b.r.i.h.RemoteopenhabBridgeHandler:348 - Try the root REST API...
14:01:05.957 [-thingHandler-1] DEBUG o.o.b.r.i.h.RemoteopenhabBridgeHandler:373 - Failed to execute the root REST API: HTTP call failed: 401 Unauthorized

This would require to analyze how openHAB Android app is handling the connection through myopenhab.

[lsafelix75]

It works on remote OH2.5.10 instance though.

[lolodomo]

My server connected to myopenhab is OH3.
Will take more time to test with OH2.
By the way, we need a solution working for remote OH2 and OH3 servers.

[lsafelix75]

I believe it has to do with some new changes on OpenHabCloud for OH3 such as X-OPENHAB-AUTH-HEADER=true, redirection which RemoteOpenhab Binding does not take into consideration. That is just my 2 cent which requires more investigation

[lsafelix75]

@lolodomo i checked on the traffic flow, I I believe it is httpclient that does not react to 302 response from remote openhab instance. I have also verified "setFollowRedirection=true"

[lolodomo]

Are you meaning myopenhab.org redirected to home.myopenhab.org?
The binding is using the common Jetty HTTP client created by openHAB.
I will check if redirection is enabled or not.
In case it is not, it could require to define a specific HTTP client for the binding because it is not a good idea to enable it for all bindings.

So finally it was not working for you too?

[lolodomo]

I just checked and the used HTTP client follows redirections (until 8 levels).
As nothing special is set when it is created by the openHAB core framework; I assume this is the Jetty default.
https://github.com/openhab/openhab-core/blob/46666eb169d8f1b02cf7a2f3f5b54bc83c0784ed/bundles/org.openhab.core.io.net/src/main/java/org/openhab/core/io/net/http/internal/WebClientFactoryImpl.java#L238

And even the request is tagged to follow redirects.

[lolodomo]

Here are what I find in the response headers:

response header WWW-Authenticate = Basic realm="Users"
response header WWW-Authenticate = Bearer realm="Users"

[lolodomo]

I got success for HTTP requests with this kind of code:

            AuthenticationStore auth = httpClient.getAuthenticationStore();
            auth.addAuthentication(new BasicAuthentication(new URI(restUrl), "Users", username, password));

Remains SSE requests...

[lsafelix75]

Are you meaning myopenhab.org redirected to home.myopenhab.org?
The binding is using the common Jetty HTTP client created by openHAB.
I will check if redirection is enabled or not.
In case it is not, it could require to define a specific HTTP client for the binding because it is not a good idea to enable it for all bindings.

So finally it was not working for you too?

Yes it isn't working on OH3 because your code use /rest to check OH3 availability and etc. But the actual path is "/rest/?" Hence OH3 replies with 302 and Location pointing to /rest/?. Somehow httpckient ignore that response and timeout. Nevertheless the concept of adding in Username and password is correct and it is working as I can see the /rest request is punching through private openhanhab cloud

[lolodomo]

I run /rest path to retrieve the different rest URL provided by the server. Then the used Rest URLs are the one provided by the server.

I can try with /rest/?
Maybe this is myopenhab that triggers this redirection?

And I will try to disable redirection and see if I get a 302 error.

[lolodomo]

Thank you very much for your help to analyze the problem.

The code is now working if I setup "/rest/?" as restPath setting.
If I keep the default path ("/rest") and disable "follow redirect", I get the 302 status with the Location header pointing to "/rest/?"

I have everything in hands to finalize the change.

I have to check if "/rest/?" could become the default REST path (in replacement to "/rest").
And I have to disable "follow redirect" and handle status 302.

[lsafelix75]

Thank you very much for your help to analyze the problem.

The code is now working if I setup "/rest/?" as restPath setting.
If I keep the default path ("/rest") and disable "follow redirect", I get the 302 status with the Location header pointing to "/rest/?"

I have everything in hands to finalize the change.

I have to check if "/rest/?" could become the default REST path (in replacement to "/rest").
And I have to disable "follow redirect" and handle status 302.

Cool

[lolodomo]

I discovered that even with a direct server access (from the local network), if I use "/rest" as endpoint, my request is redirected to "/rest/".
If I use "/rest" to access the server through openHAB Cloud, it is redirected to "/rest/?".
In both case, using "/rest/" avoids a redirection. So it must become the default value.

Regarding the access through openHAB Cloud using the invalid endpoint ("/rest"), there are in fact two redirects:

1. ffirst code 302 with the HTTP URL
2. finally code 301 with the HTTPS URL

I am now just telling me that I should disable the authorization header in requests in case HTTP protocol. is used and I should use it only in case HTTPS is used. This was not a real problem when using the binding in the local network but now that we could connect through the Net, I should take care to not provide these headers for unsecured requests. I will probably add a new setting to let users doing it but after enabling this setting.

[lolodomo]

@lsafelix75 : I have still one remaining problem, It concerns the REST API which are secured. I use one of them to retrieve the list and state of things on the remote server. For this one, I provided the double authorization headers, one Basic and one Bearer. Unfortunately, myopenhab is returniong a 400 bad request !
Any idea why ? Maybe it makes no sense to provide two different authorization types in the same request.

So at the moment, I have something working but without all features.

[lolodomo]

interesting, if I open MainUI from myopenhab in my WEB browser and then get the admin privilege, then the browser is just displaying a blank page ! Using MainUI in admin mode through myopenhab is apparently not possible.

Issue opened to try to understand what is wrong: openhab/openhab-webui#907

[lsafelix75]

Another issue tht I have noticed is your code uses the returned URLs for items, site maps directly instead of appending the domain name with the cloud url. I'm not sure whether this should be catered by remoteopenhab binding or openhabcloud. You will notice it if you use different port than standard one as the replied links' url do not have port included.

[lolodomo]

Yes I see there is no port in the returned URLs but I thought it was only becayse the default port (443) is used.
By the way, I can't change myopenhab ports !
I assume this is something possible only if you have hosted your own openHABCloud instance (which is not my case).

951 [OH-safeCall-1] DEBUG o.o.b.r.i.h.RemoteopenhabBridgeHandler:127 - Initializing remote openHAB handler for bridge remoteopenhab:server:oh3
14:53:52.954 [OH-safeCall-1] DEBUG o.o.b.r.i.h.RemoteopenhabBridgeHandler:153 - REST URL = https://myopenhab.org:443/rest/
14:53:52.957 [-thingHandler-1] DEBUG o.o.b.r.i.h.RemoteopenhabBridgeHandler:334 - Try the root REST API...
14:53:52.963 [-thingHandler-1] DEBUG o.o.b.r.i.r.RemoteopenhabRestClient:521 - Request GET https://myopenhab.org/rest/ (provided url https://myopenhab.org:443/rest/
14:53:53.707 [-thingHandler-1] DEBUG o.o.b.r.i.r.RemoteopenhabRestClient:153 - REST API version = 4
14:53:53.708 [-thingHandler-1] DEBUG o.o.b.r.i.r.RemoteopenhabRestClient:158 - REST API items = https://myopenhab.org/rest/items
14:53:53.708 [-thingHandler-1] DEBUG o.o.b.r.i.r.RemoteopenhabRestClient:159 - REST API things = https://myopenhab.org/rest/things
14:53:53.708 [-thingHandler-1] DEBUG o.o.b.r.i.r.RemoteopenhabRestClient:160 - REST API events = https://myopenhab.org/rest/events

The port is suppressed by Jetty when building the request ! Maybe that is the reason why the returned URLs in the response have no port.
What contain your logs exactly in your case ?

[lsafelix75]

I observed the same with your. Port is just truncated. I guess there are only 2 options, either you change it in your code or have to trace who alter this, either openhabcloud or remote openhab connector.

[lolodomo]

In the case of myopenhab, the port is truncated because useless (it is the default HTTPS port - 443). So I see no problem here.

In case the returned URLs are without port while port is not 443, this is a bug but not a remote openHAB binding bug. An issue has to be opened for that. I assume this bug only affects users not using myooenhab but a dedicated openHAB Cloud instance with not standards ports. Hopefully it probably concerns only few expert users all around the world ;)

[lolodomo]

And URLs returned by my server include port 8080 or 8443 so this is clearly not a OH server bug but probably an openHAB cloud bug. Issue to be opened here https://github.com/openhab/openhab-cloud

[lolodomo]

I finally found the solution to my last problem: I must use header X-OPENHAB-TOKEN rather than Authorization.
@lsafelix75 : you give me a very good hint when mentioning X-OPENHAB-AUTH-HEADER.

[lolodomo]

The PR is now finished.
Here is a jar for testing:
org.openhab.binding.remoteopenhab-3.1.0-SNAPSHOT.zip

[lsafelix75]

Yes, this code seems to working after making some changes on OpenhabCloud.

[lolodomo]

In case your changes in your own openHAB Cloud instance fix a general bug in openHAB Cloud, please propose your fix as a PR to the openHAB Cloud project. This will benefit to other users.

[lsafelix75]

Yes, bug request has already submitted to their github link

…

On 14 Feb 2021, 17:07 +0800, lolodomo ***@***.***>, wrote: In case your changes in your own openHAB Cloud instance fix a general bug in openHAB Cloud, please propose your fix as a PR to the openHAB Cloud project. This will benefit to other users. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.