fix(oauth): use dynamic HA instance URL for redirect_uri (closes #19)#37
fix(oauth): use dynamic HA instance URL for redirect_uri (closes #19)#37daboynb wants to merge 1 commit into
Conversation
OAUTH2_CALLBACK_URL was hardcoded to http://homeassistant.local:8123 which only resolves on HAOS via mDNS. HA Container, HAOS without mDNS, and instances behind a reverse proxy / Tailscale Funnel all break during OAuth setup with DNS_PROBE_POSSIBLE / 404 on the callback URL. Users currently work around it by manually pinning homeassistant.local in /etc/hosts on the OAuth-initiating client. Compute the redirect at runtime via homeassistant.helpers.network.get_url(), which is the upstream-recommended way to obtain the instance URL. Fall back to the previous hardcoded value if get_url() raises NoURLAvailableError (e.g. very early in startup). Closes Connectlife-LLC#19.
|
@daboynb I'm not able to get this to work - I get an error message whenever the redirect URL is different from I wonder if ConnectLife has to whitelist additional redirect URLs, at least |
|
I switched to the https://github.com/oyvindwe/connectlife-ha integration, and everything works flawlessly without any code changes. |
Ah, yes, I was actually trying to add OAuth to my integration, but it will only work for HAOS or using the DNS hack. |
|
Ha, I just realized that repo is actually yours ahah |
Summary
Replace the hardcoded OAuth redirect URL with a runtime-computed value based on the actual Home Assistant instance URL.
Currently
oauth2.py:17hardcodes:homeassistant.localonly resolves on HAOS via mDNS. On HA Container, HAOS without mDNS, or instances behind a reverse proxy / Tailscale Funnel the OAuth setup flow lands on a callback URL the browser can't reach (DNS_PROBE_POSSIBLE/ 404). Users currently work around it by manually pinninghomeassistant.localin/etc/hostson the OAuth-initiating client.This PR derives the redirect from
homeassistant.helpers.network.get_url(), the upstream-recommended way to obtain the HA instance URL with proper internal/external precedence. Falls back to the previous hardcoded value only ifget_url()raisesNoURLAvailableError(e.g. very early in startup).Closes
Lemonezzz, 2025-12-07) — same symptom verbatim: "When using Google authorization, it transfers to an address like: http://homeassistant.local:8123/auth/external/callback?code=... if you manually remove the .local from the link, then it says Completed".Compatibility test (existing tokens)
The Hisense OAuth backend was tested live against
https://oauth.hijuconn.com/oauth/tokenwith an existing user's refresh_token (issued previously with the hardcodedhomeassistant.localredirect_uri), to verify the change does not break already-authenticated users:grant_type=refresh_tokenrequestredirect_uri=http://homeassistant.local:8123/...redirect_uriredirect_uri(http://192.168.1.4:8123/...)Additionally, after a successful refresh the original refresh_token remained valid on subsequent calls (server is not single-use), so existing installations whose tokens were issued under the old hardcoded URL keep working as
redirect_urichanges value across refreshes — the Hisense backend does not enforce a match against the authorize-time URL on the refresh grant.Diff
Test plan
ast.parse) passeshttps://oauth.hijuconn.com/oauth/token(see table above)homeassistant/helpers/network.py/etc/hostsworkaround) — to be verified by maintainer / community on next release