mirror of
https://github.com/gesellix/Bose-SoundTouch.git
synced 2026-08-18 16:46:17 +00:00
The speaker firmware constructs the OAuth host by appending "oauth" to the first label of the configured streaming hostname (aftertouch.lan → aftertouchoauth.lan, used by both Spotify and Amazon Music token refresh). AfterTouch's DNS server previously only hijacked the hardcoded list of Bose hostnames, so operators self-hosting at a custom hostname had to add the OAuth alias themselves — and the amazon-music-oauth.md / spotify-overview.md docs incorrectly claimed the DNS server handled it automatically. ofthesun9 (#337) caught this via the worst variant: IP-based serverURL (192.168.0.30 → 192oauth.168.0.30), which is a malformed hostname no DNS resolver can answer for. There is no clean DNS workaround for the IP case — the operator must use a hostname. Three changes: - pkg/discovery/dns.go DeriveOAuthHostnames parses the configured serverURL, derives <first-label>oauth.<rest> when the host is a hostname (not IP), and adds it to the DNSDiscovery hijack list. IP serverURLs deliberately yield no derivation — the malformed name isn't worth handling and the new health check surfaces the trap. - New checks_oauth_target health check fires a Warning when serverURL is an IP literal, with a concrete example of the malformed name (`192oauth.168.0.30`) and a ManualCommand pointing at the switch. - amazon-music-oauth.md and spotify-overview.md rewritten: drop the false "automatic" claim, document the three resolution paths (AfterTouch DNS + speaker resolves via it / external LAN DNS / per-speaker /etc/hosts), and explicitly flag IP-based --server-url as incompatible with OAuth on either provider. Tests cover the derivation matrix (hostname / IPv4 / IPv6 / single label / empty / garbage URL), shouldIntercept's new behaviour (derived host hit, base host not auto-hijacked, case-insensitive), the health check's four states, and the malformed-host helper. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>