[openhabcloud] Add api token option for local openhab connection

[SchaeferDa]

I had the same problem as @DejanBukovec in #8979 and found a solution that worked for me and was quite simple.

My solution simply adds an API token to any forwarded API request that goes to the local openHAB instance and makes this API token configurable in the UI settings.

But I would say that it is rather a kind of a workaround. So whether this should go into the productive addon I cannot decide.

I mainly wanted to share my code, so that others with the same problem, do not have to do it again...

There is also one thing that bothers me about my solution, but I haven't found a solution for it unfortunately ...my first time working on openHAB's source code... The API token remains permanently visible in the UI settings. Doesn't bother me that much personally, but I think this should be changed.

[lolodomo]

@kaikreuzer : would you like to comment /review ?

[ghys]

The UI would redirect the user automatically to the authorization page (as it does locally) even over openHAB Cloud, the problem is that the server responds with a weird HTTP 401 OK rather than 401 Unauthorized (as Jetty does) which would be more correct. It's mentioned in #8979 (org.openhab.habdroid.util.HttpClient$HttpException: OK). I would definitely prefer fixing this rather than having to introduce a workaround like this, tbh.

[SchaeferDa]

The UI would redirect the user automatically to the authorization page (as it does locally) even over openHAB Cloud, the problem is that the server responds with a weird HTTP 401 OK rather than 401 Unauthorized (as Jetty does) which would be more correct. It's mentioned in #8979 (org.openhab.habdroid.util.HttpClient$HttpException: OK). I would definitely prefer fixing this rather than having to introduce a workaround like this, tbh.

When I access the frontend via openHAB cloud, I am not automatically redirected to the authorization page, but I can open it via the standard icon on the bottom left corner. Unfortunately, this does not help me, because I only use openHAB cloud to control items via Google assistant. So as soon as you want/must use the "remote API" with openHAB cloud, this unfortunately achieves nothing.

[ghys]

I see. OH's authorization layer accepts tokens (access tokens or API tokens) both in the Authorization (Bearer) & X-OPENHAB-TOKEN HTTP headers. This is designed like this specificially to deal with the double authorization needed in the remote scenario.

So when operating openHAB locally you would have have requests like this:

GET /rest/items HTTP/1.0
Authorization: Bearer <access_token or API token>

When using openHAB Cloud (e.g. home.myopenhab.org) you would have this:

GET /rest/items HTTP/1.0
Authorization: <OH Cloud credential>
X-Openhab-Token: <access_token or API token>

Wouldn't it make sense to have clients like the Google Assistant connector have a setting to store the OH API token and use this 2nd header to authorize to OH rather than doing it at the OH cloud connector level?

[lolodomo]

@SchaeferDa @ghys : what is the status of this PR ?

[SchaeferDa]

@SchaeferDa @ghys : what is the status of this PR ?

I would not consider my proposed solution a "good final solution" either. My intention was only to create a short-term solution so that the Google Assistant integration works again with "official" releases. (Personally, I'm running my OH instance with my customization, which unfortunately makes updating not so easy anymore :D)

I can't say anything about the Google Assistant Connector, but I as a user would have problems loading a token of my local OH instance in a "third-party hosted" service.... I would consider, as also mentioned before, as the best option that the openHAB cloud integration (local) handles the authentication and there is no need for "double" authentication, but I cannot implement this.

So: I suggest to implement the workaround like this for a short term solution, because I think one of the alternative solutions would be better, but more time consuming and not ready as a short term solution.

[jlaur]

@SchaeferDa - can you resolve the merge conflict?

[lsiepel]

As the proposal was a short term solution and there was two years of inactivity, I conclude we can’t get this PR to the finish line and close it. If there is still a need, feel free to re-open or re-use the code.