mirror of
https://github.com/gesellix/Bose-SoundTouch.git
synced 2026-08-19 17:16:16 +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>
Bose SoundTouch Toolkit Documentation
Welcome to the documentation for the Bose SoundTouch Toolkit. This comprehensive toolkit helps you keep your Bose SoundTouch speakers functional even after the Bose Cloud shutdown in May 2026, with enhanced local management and monitoring capabilities.
🚀 Start Here
For New Users
- Complete Migration Guide - Step-by-step guide from Bose Cloud to local control
- Getting Started - Quick introduction to the toolkit
For Existing Users
- Cloud Shutdown Survival Guide - Prepare for the May 2026 shutdown
- Backup Tool - Back up your cloud account and speaker data before shutdown
- SoundTouch Service Guide - Advanced service configuration
📋 Essential Documentation
The documentation is organized into three main categories:
1. User Guides - For everyday users migrating and managing devices
2. Technical Reference - For developers and advanced configuration
3. Concept Documentation - For contributors and system architects
🗂 Documentation Structure
🗂 User Guides
Migration & Setup
- Complete Migration Guide - 📖 Main guide for migrating from Bose Cloud
- Cloud Shutdown Survival Guide - Prepare for service shutdown
- Migration & Safety Guide - Advanced migration strategies
- Initial Device Setup - First-time device configuration
- Raspberry Pi Setup - Installing on Raspberry Pi
Daily Management
- SoundTouch Service Guide - Service operation and maintenance
- Troubleshooting - Common issues and solutions
- HTTPS Setup - Secure connections
- Deployment Guide - Production deployments
Advanced Features
- MAC Address Mapping - Device identification
- CLI Reference - Command-line tools
- Backup Tool - Cloud account and speaker data backup
- IoT Implementation Guide - IoT integrations
- MQTT Integration Design - MQTT setup
📚 Technical Reference
API Documentation
- API Endpoints - REST API reference
- Spotify Account Addition - Technical requests for Spotify
- WebSocket Events - Real-time events
- Zone Management - Multi-room control
- Preset Management - Preset operations
Analysis & Research
- Upstream URLs - Bose service endpoints
- Device Redirect Methods - Migration techniques
- IoT Configuration Analysis - Device configurations
- IoT Config Summary - Configuration summaries
Device Lifecycle & Network Independence
- Device Lifecycle and /power_on Enhancement - Complete analysis of device registration and network independence improvements
- /power_on Implementation Guide - Technical implementation details for enhanced device management
🏗 Concept Documentation
Enhanced Service Architecture
- Concept Overview - High-level architecture vision
- Upstream Service Simulation - Complete concept design
- Implementation Plan - Development roadmap
- Technical Specification - Detailed specifications
Development Planning
- Implementation Roadmap - Project phases and milestones
💡 Quick Reference
Common Tasks
- Migrate first device: Follow Migration Guide Step 5
- Check device health: Dashboard → Devices → [Device Name] → Health Status
- Backup configuration: Dashboard → Settings → Backup → Create Backup
- Add new device: Dashboard → Devices → Discover Devices → Register
Getting Help
- Issues & Bugs: GitHub Issues
- Questions & Discussion: GitHub Discussions
- Documentation: Check troubleshooting guides first
- Community: Share experiences and help others
For a complete list of all documents, see the Summary.