#Did you enable hassio_api: true in your

1 messages · Page 1 of 1 (latest)

glacial fiber
#

Yes. Everything worked fine, if I install the addon locally (copy the sources, etc. into the folder /addons/<slug_name> and using the same config.yaml . In this case the variable appeared in the addon. If I install the same code via an image from ghcr.io, the variable does not show up. The addon itself can be installed that way and works, but I have to supply the token externally, which isn't an option for the productive use.

flint ember
#

got it - looking further at my own link i see that I'm using one of the non-elevated supervisor APIs right now (/discovery and /addons/self) so I mistakenly assumed i had your scenario working. Tonight I'll try hitting the true HA APIs and see if i can't get it working + share results. thanks for the warning!

#

can you share exactly which target endpoint on the supervisor api you're trying to hit so i can try too?

#

a full curl-equivalent would be great if you have it

glacial fiber
#

I simply call
self.token = os.getenv("SUPERVISOR_TOKEN")
which works in the local version, but not in the docker version.

#

In the docker version this call returns None.

glacial fiber
#

Now I achieved a little progress: By adding the line

#

"#!/usr/bin/with-contenv sh"

#

to my start.sh, the environment variables appear inside my addon. However, the authentification process still fails.

#

Just to keep it in mind: Its still the same code, which works with the internally built addon.

#

Strange behavior and not well documented...

flint ember
#

i'm with you on the documentation front.. interesting, i'm not using that shebang, i am using bashio..

#

specifically #!/usr/bin/env bashio

#

i was able to see the valid supervisor token last night which wasn't quite a "locally built" but i didn't push to GHCR and try to reinstall on the remote HASS instance to prove it worked

#

in case it helps with debugging, i'm deriving from one of their debian base images in case there are other random goodies in there that happen to make it work

glacial fiber
#

So it seems, that with that additional line I get the token. But the connection still fails.

#

This is from the logs:
2024-04-18 21:26:11 DEBUG websockets.client: = connection is CONNECTING
2024-04-18 21:26:11 DEBUG websockets.client: > GET /core/websocket HTTP/1.1
2024-04-18 21:26:11 DEBUG websockets.client: > Host: supervisor
2024-04-18 21:26:11 DEBUG websockets.client: > Upgrade: websocket
2024-04-18 21:26:11 DEBUG websockets.client: > Connection: Upgrade
2024-04-18 21:26:11 DEBUG websockets.client: > Sec-WebSocket-Key: Cxn1+MsAmAVVhEUutSgaVQ==
2024-04-18 21:26:11 DEBUG websockets.client: > Sec-WebSocket-Version: 13
2024-04-18 21:26:11 DEBUG websockets.client: > Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
2024-04-18 21:26:11 DEBUG websockets.client: > Authorization: Bearer 60da4213c1fc13e8703786b5d73c01b9ece07eb53553ec98b6ebd38d4cec6275bdb77109448cac10be61866281ee31ca6d374442768d1705
2024-04-18 21:26:11 DEBUG websockets.client: > User-Agent: Python/3.11 websockets/12.0
2024-04-18 21:26:11 DEBUG websockets.client: < HTTP/1.1 502 Bad Gateway
2024-04-18 21:26:11 DEBUG websockets.client: < Content-Type: text/plain; charset=utf-8
2024-04-18 21:26:11 DEBUG websockets.client: < Content-Length: 16
2024-04-18 21:26:11 DEBUG websockets.client: < Date: Thu, 18 Apr 2024 19:26:11 GMT
2024-04-18 21:26:11 DEBUG websockets.client: < Server: Python/3.12 aiohttp/3.9.3
2024-04-18 21:26:11 DEBUG websockets.client: ! failing connection with code 1006
2024-04-18 21:26:11 DEBUG websockets.client: x half-closing TCP connection
2024-04-18 21:26:11 DEBUG websockets.client: = connection is CLOSED

#

The connection seems to be established with the SUPERVISOR_TOKEN as bearer token

#

But than it comes with error code 1006.

#

Here is another logging example, which looks a bit different:

#

After the message: "connection is OPEN" the server asks "auth required:

#

2024-04-18 21:38:20 DEBUG websockets.client: < TEXT '{"type":"auth_required","ha_version":"2024.4.3"}' [48 bytes]
2024-04-18 21:38:20 DEBUG websockets.client: > TEXT '{"type": "auth", "access_token": "788dba363765f...184e6f8c21acc2415dc43"}' [148 bytes]
2024-04-18 21:38:20 DEBUG websockets.client: < TEXT '{"type":"auth_invalid","message":"Invalid access"}' [50 bytes]
2024-04-18 21:38:20 DEBUG websockets.client: < CLOSE 1000 (OK) [2 bytes]
2024-04-18 21:38:20 DEBUG websockets.client: = connection is CLOSING
2024-04-18 21:38:20 DEBUG websockets.client: > CLOSE 1000 (OK) [2 bytes]

#

My code answered with the SUPERVISOR_TOKEN as access_token, but this fails. Any idea?

#

Thanks for helping me!!!

#

2024-04-18 21:38:20 DEBUG websockets.client: > Authorization: Bearer 788dba363765f4533e2c19bf92caada5ba39ef07fb2333c20ccef205957cae1dc8ea303fb11a580c540da7edd5d184e6f8c21acc2415dc43
2024-04-18 21:38:20 DEBUG websockets.client: > User-Agent: Python/3.11 websockets/12.0
2024-04-18 21:38:20 DEBUG websockets.client: < HTTP/1.1 101 Switching Protocols
2024-04-18 21:38:20 DEBUG websockets.client: < Upgrade: websocket
2024-04-18 21:38:20 DEBUG websockets.client: < Connection: upgrade
2024-04-18 21:38:20 DEBUG websockets.client: < Sec-WebSocket-Accept: GX+OmKhJwYB8o4grWCqjjKVFLVg=
2024-04-18 21:38:20 DEBUG websockets.client: < Sec-WebSocket-Extensions: permessage-deflate
2024-04-18 21:38:20 DEBUG websockets.client: < Date: Thu, 18 Apr 2024 19:38:20 GMT
2024-04-18 21:38:20 DEBUG websockets.client: < Server: Python/3.12 aiohttp/3.9.3
2024-04-18 21:38:20 DEBUG websockets.client: = connection is OPEN
2024-04-18 21:38:20 DEBUG websockets.client: < TEXT '{"type":"auth_required","ha_version":"2024.4.3"}' [48 bytes]
2024-04-18 21:38:20 DEBUG websockets.client: > TEXT '{"type": "auth", "access_token": "788dba363765f...184e6f8c21acc2415dc43"}' [148 bytes]
2024-04-18 21:38:20 DEBUG websockets.client: < TEXT '{"type":"auth_invalid","message":"Invalid access"}' [50 bytes]
2024-04-18 21:38:20 DEBUG websockets.client: < CLOSE 1000 (OK) [2 bytes]
2024-04-18 21:38:20 DEBUG websockets.client: = connection is CLOSING
2024-04-18 21:38:20 DEBUG websockets.client: > CLOSE 1000 (OK) [2 bytes]

#

For a better understanding, this is the complete log of the second case. The two cases occur in alternating sequence.

flint ember
#

interesting - so it really didn't seem to like the token

#

it sounds like your addon might not actually have the right permissions?

#

just to debug, have you tried adding all those permission flags on the addon?

#

i can't paste a screenshot here, but

#

i'm a little unclear on the 502 vs your second round of logs

#

502 sounds like something wasn't ready/crashing on the remote side but your second set of logs look like healthy services + standard auth rejection

#

are you able to get the REST API working without the added complexity of websocket?

flint ember
#

BTW I also see a HASSIO_TOKEN which is different from the supervisor token, don't know if you tried that

glacial fiber
#

In my case, the HASSIO_TOKEN was always identical to the SUPERVISOR_TOKEN.

#

I don't worry so much about the 502, it says something of a half-closing TCP connection. I don't know why, but the next attempt usually went fine.

#

I am still confused, because the SUPERVISOR_TOKEN worked in the internally built version, which should also be a docker image, isn't it? Could it be that the s6-overlay stuff affects the token logic?

#

Another thing, I don't understand, is the fact, that the server asks "auth-required", although I have sent the bearer token.

glacial fiber
#

I could figure out that the 502 error is due to the fact that my code did not close the websocket from client's side, too. It is not sufficient that the server closes it, even if the log told that the connection is closed. However, the question with the "auth_required" still remains...

glacial fiber
#

There must be a severe bug in Home Assistant! I run two Raspberries, a Raspi 4 and a Raspi 5, both with the same software, core 2024.4.3, supervisor 2024.04.0, HAOS 12.2 . On both systems the SUPERVISOR_TOKEN taken by the Python command os.getenv("SUPERVISOR_TOKEN") does not work.

#

But on the Pi4, I can pick the SUPERVISOR_TOKEN from the terminal addon by typing "printenv SUPERVISOR_TOKEN". If I use this token instead of the one from the Python os.getenv, the authentification is granted and the software runs fine.

#

Unfortunately, on my Pi5 this workaround does not help.

#

I don't believe that this behavior is intended.

glacial fiber
#

I opened an issue report:

glacial fiber
#

I found the reason for my "strange things no 2": On the Pi5 I used the "Terminal and SSH" addon, on the Pi4 the "Advanced SSH and Web Terminal" addon. I switched to the latter on my Pi5 and got the working token typing 'printenv SUPERVISOR_TOKEN'.

However, the behavior is weird. Under which circumstance supervisor tokens are generated?

flint ember
#

interesting - I believe the reason for strange thing #2 might be that supervisor tokens are actually addon-specific. Perhaps the Advanced addon is requesting more permissions in the manifest so the advanced addon generates a more powerful token for the operation you're trying to do?

flint ember
#

though none of that is really explained by the local difference - maybe for local debugging you get a default-god-mode token?

glacial fiber
#

I agree, the SUPERVISOR_TOKEN must be an addon-specific token, as the token I see inside of my addon is different from the one I get in the terminal. However, why doesn't match this addon-specific token match when it is used? And why matches the token of the advanced ssh addon?

#

This is why I strongly believe that it must be a bug in the token handling.

#

And the documentation is really bad!

flint ember
#

are you able to share your config.yaml? I wonder if you have homeassistant_api: True in your addon that isn't working?

#

hopefully there is an update on the issue you posted as well!

glacial fiber
#

I tried it with 'homeassistant_api: true', too, but it didn't make a difference, so I removed it again.

#

And it is described to work this way. What is this SUPERVISOR_TOKEN for, that I get in my addon environment, if not for exactly that purpose?

glacial fiber
#

I found the problem: The first python command,
self.websck = await websockets.connect("ws://supervisor/core/websocket", extra_headers={"Authorization": f"Bearer {self.auth_token}"}, open_timeout=1)
made the problem, although it seemed to work fine. Somewhere in the system, the timeout is raised and the connection closed, while the next steps of the authentification take place.

#

With the supervisor_token of the ssh-addon or the local addon, it seem to work a bit faster...

#

I set the timeout to 2 seconds and the code runs fine. I'm happy, but I can't believe such a strange behavior...

#

Thanks for your help.

flint ember
#

amazing - thanks for reporting back with the cause, my code right now doesn't set any explicit timeouts while i play around, hence why i probably couldn't repro but it's great to know to keep an eye out!

#

(also i am kind of suprised there is no proper python ws client package and only javascript so we have multiple efforts recreating that)