Long Lived Access token authentication fails

[Caroga]

Hi,

I hope I just have a missing configuration here and not a bug but let's see.

I use the latest docker version as provided by Causticlab 0.4.0. I've configured the following environment variables:

HC_BASEPATH=/hass-config/
HC_API=http://homeassistant:8123/api/                        <- docker interal routing
HC_HASS_WS_API=wss://homeassistant.url.tld/api/    <- browser url
HC_HASS_API_PASSWORD=token

Problem

1. When trying to observe events by websockets the connection is closed instantly.
2. When sending commands to HASS, like a restart, it fails.

Ha-configurator logfile:

WARNING:2020-08-22 13:42:33,417:__main__:<urlopen error [Errno 111] Connection refused>

Homeassistant logfile:

[homeassistant.components.http.ban] Login attempt or request with invalid authentication from 10.0.6.36

Question Am I missing a certain configuration or not using the right set here?

[danielperna84]

To me it's looking fine. Don't know what to suggest. Maybe it starts working with a settings.conf that contains the values.

[Caroga]

I will add the settings.conf; using the docker container, where should this be placed? Or should I reference it from the volume and overwrite the entrypoint to include the configuration?

sidenote: I was also hoping the version issue could be the culprit as it might have been a bug in a prior version but this doesn't ring a bell?

[danielperna84]

I'm not really familiar with Docker-setups, so I have to refer you to the documentation for that.

I don't think the version is the issue here. Even though it's been a while since I've worked on this, I believe from 0.3.7 to 0.4.0 no significant changes related to the access token have been made. It was mainly refactoring to make the package for pip and including some JavaScript code which usually was fetched from cloud resources. The Token-stuff has been stable for a long time. So that shouldn't be the problem in this case.

[Caroga]

During the restructuring of the Docker image in the downstream repository I found how to load the settings.conf file. I now have successfully connected the configurator to my homeassistant.

I am now able to see my entities as well to restart homeassistant. However, the websocket is still failing. I do feel this might be a configuration issue so I think closing this issue would be oke.

Some brainteasers: Configuring the application using environment variables is working except for the token somehow. I was able to configure the base-path of the application in the same way I supplied the token; however the base-path configuration worked and token did not. Could you maybe run this on your end to distinguish between the platforms?

[danielperna84]

The environment variables are resolved programmatically here. So there's not really a distinction between them. If it works for one, it should work for the others. And I can say in my case it's working via environment variables. I have installed the configurator via pip and have a sastemd unit which handles everything. There I have a line like Environment=HC_HASS_API_PASSWORD=abc.def.ghi, and it's working without problems.

Anyways, the fact that you get the entities and can restart HA tells us, that the configurator knows about the token and is using it. For listening to the events across the websocket, the token just populates the corresponding field in the UI. The connection itself is established completely client-side in the browser. Do you have valid certificates? And which browser are you using? I have seen before, that secure websocket connections fail in Firefox if it's not a trusted certificate. To resolve this, you have to manually browse to the API URL (with https instead of wss) to be able to add an exception for the untrusted certificate.

In general you should have a look at the JavaScript console of your browser for further hints.

[Caroga]

The environment variables are resolved programmatically here. So there's not really a distinction between them. If it works for one, it should work for the others. And I can say in my case it's working via environment variables. I have installed the configurator via pip and have a sastemd unit which handles everything. There I have a line like Environment=HC_HASS_API_PASSWORD=abc.def.ghi, and it's working without problems.

Yeah I figured. I have no to limited experience in Python so further debugging would be extremely time consuming for me so I think I might go around testing the different ways of configuring the application (env-based, file-based) and try to find out a specific combination (if any) where this occurs.

I was also thinking about quotes, I find that the settings.conf file needs quotes around the values since it's a json structure. Do you use quotes in your systemd configuration? Because I did not in my docker-compose file: I used it as a key value struct HC_HASS_API_PASSWORD=token.token.token

Anyways, the fact that you get the entities and can restart HA tells us, that the configurator knows about the token and is using it. For listening to the events across the websocket, the token just populates the corresponding field in the UI. The connection itself is established completely client-side in the browser.

Yes, the API is now working and I can do things. On the websocket however I noticed that in the situation where I populated the token via environment variables in docker the password field was also pre-filled. This furthermore pushed me into thinking using quotes around the value or not, since it was pre-filled but not allowing connections.

Do you have valid certificates? And which browser are you using? I have seen before, that secure websocket connections fail in Firefox if it's not a trusted certificate. To resolve this, you have to manually browse to the API URL (with https instead of wss) to be able to add an exception for the untrusted certificate.

Yes; running letsencrypt on a local RPI. I am using Chrome browsers across several devices (windows and Linux based).

In general you should have a look at the JavaScript console of your browser for further hints.

I will, but I got distracted by some other things that needed my attention that I dropped this yesterday. I will do some more debugging and report back with my findings (if any).

[danielperna84]

I was also thinking about quotes, I find that the settings.conf file needs quotes around the values since it's a json structure. Do you use quotes in your systemd configuration? Because I did not in my docker-compose file: I used it as a key value struct HC_HASS_API_PASSWORD=token.token.token

The quotes in the file are required because it's a JSON file. It would be a syntax error to have a string without quotes. For the env-variable you don't need quotes, and I don't have quotes in my unit-file.

Yes, the API is now working and I can do things. On the websocket however I noticed that in the situation where I populated the token via environment variables in docker the password field was also pre-filled.

If the value is not prefilled, the API shouldn't work as well. If it does, then that's because you have configured HA to always allow connections from certain locations. The token used to communicate with the API and the prefilled value in the UI are exactly the same. So if one is missing, the other is missing too. So if one is working and the other is not, it must be a policy-thing outside of the scope of the configurator.