mirror of
https://github.com/gesellix/Bose-SoundTouch.git
synced 2026-08-18 16:46:17 +00:00
feat: improve Bose SoundTouch parity, Spotify integration, and data reliability (#138)
feat: improve Bose SoundTouch parity, Spotify integration, and data
reliability
- Update XML marshaling for ServicePreset and ServiceRecent to match
Bose parity requirements.
- Add support for adding music sources via
`/streaming/account/{account}/source`.
- Implement HandleBoseAccountToken for Spotify OAuth code exchange and
token persistence.
- Implement atomic file writes in the datastore to prevent data
corruption.
- Add startup logic to initialize default sources for existing devices.
- Expand test coverage with new parity regression and Spotify
integration tests.
---------
Co-authored-by: Junie <junie@jetbrains.com>
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
This commit is contained in:
Tobias Gesellchen
Junie
@@ -0,0 +1,114 @@
|
||||
# Bose SoundTouch Device Setup Flow
|
||||
|
||||
This document details the multi-step process required to fully set up a Bose SoundTouch device, as derived from the Stockholm firmware (`setup/js/`) analysis.
|
||||
|
||||
A complete setup flow involves a sequence of local (WebSocket) and cloud (HTTP) actions that move the device from a factory-reset state to a fully registered, functional system.
|
||||
|
||||
## 1. Local Coordination Stage (WebSocket)
|
||||
|
||||
Before a device can be controlled, it must be configured on the local network and named. These actions occur via a WebSocket connection to the device on port 8080.
|
||||
|
||||
### 1.1 Language Configuration (Optional)
|
||||
If the device is in a factory-reset state, the UI typically ensures the device language matches the user's choice.
|
||||
- **WebSocket Action**: `set_language`
|
||||
- **Internal Logic**: `SetupWizard.js` handles this via `set_device_language`.
|
||||
|
||||
### 1.2 Network Configuration (WiFi)
|
||||
Configures the device to connect to a specific wireless access point.
|
||||
- **File Reference**: `setup/js/workflow_wifi_setup.js`
|
||||
- **Logic**: Triggers a site survey, then sends SSID and credentials.
|
||||
- **WebSocket Command**: `set_WIFI_OLED` or similar internal method calls to configure the network profile.
|
||||
|
||||
### 1.3 Device Naming (Rename Step)
|
||||
Assigns a user-friendly name (e.g., "Living Room") to the device.
|
||||
- **File Reference**: `setup/js/workflow_rename.js`
|
||||
- **WebSocket Action**: `name`
|
||||
- **XML Payload**:
|
||||
```xml
|
||||
<name>Living Room</name>
|
||||
```
|
||||
- **Implementation**: The `RenameDevices.do_rename_devices()` function sends this to the device. The device then updates its local name and mDNS/SSDP broadcasts.
|
||||
|
||||
## 2. Cloud Interaction Stage (HTTP)
|
||||
|
||||
The device needs to be linked to a Bose "Marge" account to enable cloud-based features and music services.
|
||||
|
||||
### 2.1 Account Creation (Registration)
|
||||
If a user doesn't have an account, the setup client creates one.
|
||||
- **File Reference**: `setup/js/workflow_marge.js`
|
||||
- **Cloud Endpoint**: `POST https://streaming.bose.com/streaming/account`
|
||||
- **Payload**: XML containing name, email, password, and country.
|
||||
- **Content-Type**: `application/vnd.bose.customer-v1.0+xml`
|
||||
|
||||
### 2.2 Cloud Authentication (Login)
|
||||
The setup client must obtain a valid `accountId` and `userAuthToken` to pair the device.
|
||||
- **File Reference**: `setup/js/workflow_marge.js`
|
||||
- **Cloud Endpoint**: `POST https://streaming.bose.com/streaming/account/login`
|
||||
- **Payload**: XML containing username and password.
|
||||
- **Content-Type**: `application/vnd.bose.streaming-v1.2+xml`
|
||||
- **Result**: Returns a session token in the `Credentials` response header and the user's `account ID` in the XML body.
|
||||
|
||||
## 3. Registration Bridge (WebSocket to Cloud)
|
||||
|
||||
This is the final "pairing" step where the client tells the device which account it belongs to.
|
||||
|
||||
### 3.1 Device Registration (The "Pair" Step)
|
||||
The client sends the user's credentials to the device, which then registers itself with the cloud.
|
||||
- **File Reference**: `setup/js/workflow_add_devices.js`
|
||||
- **WebSocket Action**: `setMargeAccount`
|
||||
- **XML Payload**:
|
||||
```xml
|
||||
<PairDeviceWithAccount>
|
||||
<accountId>12345</accountId>
|
||||
<userAuthToken>jGwE... (truncated)</userAuthToken>
|
||||
</PairDeviceWithAccount>
|
||||
```
|
||||
- **Device Reaction**: Upon receiving this, the device makes its own outbound HTTP POST to the Marge service:
|
||||
`POST https://streaming.bose.com/{accountId}/devices`
|
||||
|
||||
## 4. Finalization
|
||||
|
||||
Once the registration is complete, the setup application (Stockholm) performs final cleanup. It's important to distinguish between **App State** (the Stockholm UI's persistent settings) and **Device State** (the physical speaker's configuration).
|
||||
|
||||
### 4.1 Exiting Setup Mode (App Settings)
|
||||
The Stockholm app communicates with its "native container" (the WebView bridge on iOS/Android/Windows/macOS) using a `setData` command in **JSON format**. This is an internal message to the application's persistent storage, **not a network command sent to the physical speaker**.
|
||||
|
||||
This command tells the Stockholm app which page to load on startup, effectively marking the setup as complete in the UI.
|
||||
|
||||
- **Internal Command**: `setData`
|
||||
- **Parameter**: `startupPage`
|
||||
- **Normal Value**: `index.html` (Normal mode)
|
||||
- **Setup Value**: `setup/index.html` (Setup mode)
|
||||
|
||||
**JSON Payload (Internal to Stockholm App)**:
|
||||
```json
|
||||
{
|
||||
"method": "setData",
|
||||
"params": {
|
||||
"name": "startupPage",
|
||||
"value": "index.html"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Other Common Internal Parameters**:
|
||||
- `changeStartupPage`: Set to `false` after a successful setup or update.
|
||||
- `tipsEnabled`: Set to `false` to suppress the "Getting Started" tutorials.
|
||||
- `promptUpdate`: Set to `true` if a firmware update was deferred during setup.
|
||||
|
||||
### 4.2 Device Finalization
|
||||
The physical speaker considers the setup "done" once it successfully processes the `<PairDeviceWithAccount>` XML message and completes its own handshake with the Marge cloud. There is no specific "Finalize" XML command sent to the speaker; the successful registration is the signal.
|
||||
|
||||
The `SetupWizard.js` calls `single_device_setup_done()` to trigger the internal `setData` updates described above. If these are not saved in the app's local storage, the Stockholm UI may return to the setup flow on next launch, even if the speaker is already paired.
|
||||
|
||||
---
|
||||
|
||||
## Summary of Scriptable Requirements
|
||||
|
||||
To automate a device setup using a custom tool (like `soundtouch-cli`), you must perform the following:
|
||||
1. **Configure WiFi**: (Assumed if device is reachable over IP).
|
||||
2. **Set Name**: Send the `<name>` WebSocket message (XML) to update the device identity.
|
||||
3. **Obtain Token**: Authenticate against the cloud service (Marge) via HTTP.
|
||||
4. **Pair Device**: Send the `<PairDeviceWithAccount>` WebSocket message (XML) with the account ID and token.
|
||||
|
||||
**Note**: The JSON `setData` commands are only necessary if you are building/controlling a version of the Stockholm UI itself. They are not required to configure the physical hardware.
|
||||
@@ -0,0 +1,66 @@
|
||||
# Technical Proposal: External Service Provider Abstraction
|
||||
|
||||
This document outlines a strategy to refactor the SoundTouch Service's content handling into a modular provider-based system.
|
||||
|
||||
## 1. Problem Statement
|
||||
Currently, content handling for BMX (Bose Media Exchange) services like TuneIn or RadioBrowser is deeply intertwined with the HTTP handlers and XML models. Adding a new content provider (e.g., Local Media, Podcast RSS) requires modifying several files and duplicating boilerplate code for HTTP requests and error handling.
|
||||
|
||||
## 2. Proposed Architecture
|
||||
|
||||
### 2.1 The Provider Interface
|
||||
We define a generic `ContentProvider` interface that abstracts away the source-specific logic (API calls, data parsing).
|
||||
|
||||
```go
|
||||
package provider
|
||||
|
||||
import "github.com/gesellix/bose-soundtouch/pkg/models"
|
||||
|
||||
type ContentProvider interface {
|
||||
// ID returns the unique identifier for this provider (e.g. "RADIO_BROWSER")
|
||||
ID() string
|
||||
|
||||
// Resolve returns playback details for a given content identifier
|
||||
Resolve(id string) (*models.BmxPlaybackResponse, error)
|
||||
|
||||
// Search allows finding content within this provider
|
||||
Search(query string) ([]models.ContentItem, error)
|
||||
}
|
||||
```
|
||||
|
||||
### 2.2 Provider Registry
|
||||
A central registry in `soundtouch-service` manages the lifecycle and selection of providers.
|
||||
|
||||
```go
|
||||
type Registry struct {
|
||||
providers map[string]ContentProvider
|
||||
}
|
||||
|
||||
func (r *Registry) Register(p ContentProvider) { ... }
|
||||
func (r *Registry) Get(id string) ContentProvider { ... }
|
||||
```
|
||||
|
||||
## 3. Implementation Plan
|
||||
|
||||
### 3.1 Phase 1: Modularize RadioBrowser
|
||||
1. **Extract Logic**: Move current RadioBrowser logic from `bmx.go` into a new package `pkg/service/providers/radiobrowser`.
|
||||
2. **Add Failover**: Implement the **API Failover** logic inspired by OpenCloudTouch.
|
||||
- Maintain a list of active RadioBrowser mirrors (e.g., `de1.api.radio-browser.info`, `nl1.api.radio-browser.info`).
|
||||
- Implement a round-robin or health-based selection strategy.
|
||||
3. **Implements Interface**: Ensure the new package satisfies the `ContentProvider` interface.
|
||||
|
||||
### 3.2 Phase 2: Refactor BMX Handlers
|
||||
- Update `HandleTuneInPlayback` and `HandleOrionPlayback` to use the registry.
|
||||
- The handlers will look up the provider based on the request context or URL parameters and delegate the resolution.
|
||||
|
||||
### 3.3 Phase 3: Dynamic Service Advertising
|
||||
- Modify `HandleBMXRegistry` to dynamically generate the `bmx_services.json` content based on the currently registered and enabled providers.
|
||||
|
||||
## 4. Benefits
|
||||
- **Resilience**: Centralized error handling and failover strategies for all external APIs.
|
||||
- **Extensibility**: New services can be added by simply implementing the interface and registering them at startup.
|
||||
- **Testability**: Providers can be unit-tested in isolation without mocking the entire HTTP server stack.
|
||||
- **Unified UI**: A future Web UI can query the registry to show available content sources and their statuses.
|
||||
|
||||
## 5. Next Steps
|
||||
1. Refine the `ContentProvider` interface to include metadata (icons, user-friendly names).
|
||||
2. Create a prototype for the `radiobrowser` provider with failover support.
|
||||
@@ -0,0 +1,45 @@
|
||||
# Parity Analysis: Bose-SoundTouch (Go) vs. OpenCloudTouch (Python)
|
||||
|
||||
This document provides a comparative analysis of the current Go implementation and the `scheilch/opencloudtouch` project, identifying functional gaps and potential improvements.
|
||||
|
||||
## 1. Core Architecture and Language
|
||||
- **Bose-SoundTouch (Go)**: A high-performance, strongly typed backend with a CLI and background service. Focuses on full API coverage, parity testing, and robust hardware control (DSP, zones).
|
||||
- **OpenCloudTouch (OCT)**: A modern full-stack application (FastAPI + React/TypeScript). Prioritizes user experience with a web-based setup wizard and a clean abstraction for internet radio.
|
||||
|
||||
## 2. Functional Comparison
|
||||
|
||||
| Feature | Bose-SoundTouch (Go) | OpenCloudTouch (Python) |
|
||||
|:------------------------|:-----------------------------------------------------------|:------------------------------------------------------------------------|
|
||||
| **Setup Experience** | CLI-driven or manual API calls for migration (SSH, XML). | Web-based **Setup Wizard** guides through SSH, backup, and redirection. |
|
||||
| **Radio Support** | Static integration of **RadioBrowser** and TuneIn. | Dynamic **RadioBrowserAdapter** with automatic **API Failover**. |
|
||||
| **Commercial Services** | Deep integration (Spotify priming, Pandora, Deezer, etc.). | Basic support, focus is on local content and radio. |
|
||||
| **Hardware Control** | Extensive (Bass, Treble, Soundbar levels, Clock display). | Basic playback and zone controls. |
|
||||
| **Cloud Emulation** | High-fidelity parity (mirroring, discrepancy logging). | Functional emulation for local preset/recent persistence. |
|
||||
| **Notifications** | Built-in **TTS** and custom URL audio alerts. | Not a primary focus. |
|
||||
|
||||
## 3. Key Strengths of OpenCloudTouch
|
||||
- **Guided Onboarding**: The setup wizard reduces the entry barrier for non-technical users significantly.
|
||||
- **Resilient Radio**: The API failover for RadioBrowser ensures continuous service even if specific community-hosted API instances go offline.
|
||||
- **Modern API Stack**: Uses OpenAPI and generated TypeScript types for a seamless frontend integration.
|
||||
- **Provider Abstraction**: A cleaner internal separation between the "Bose World" (XML/BMX) and external content providers (RadioBrowser).
|
||||
|
||||
## 4. Suggested Improvements for Bose-SoundTouch
|
||||
|
||||
### A. Web-based Setup Wizard (High Priority)
|
||||
- Implement a state-driven wizard in the `soundtouch-service` to handle:
|
||||
- SSH activation (checking `/remote_services` via USB).
|
||||
- Automated backup of speaker configuration.
|
||||
- Verification of DNS/Hosts redirection.
|
||||
- Expose this via a simple embedded Web UI (using Go's `embed` package).
|
||||
|
||||
### B. RadioBrowser Failover (Medium Priority)
|
||||
- Adapt the failover logic from OCT:
|
||||
- Periodically refresh the list of available RadioBrowser API servers.
|
||||
- Implement a retry mechanism that switches servers on 5xx errors or timeouts.
|
||||
|
||||
### C. External Service Abstraction (Medium Priority)
|
||||
- Refactor the hardcoded BMX logic into a more modular **Provider System** (see `EXTERNAL-SERVICES-ABSTRACTION.md`).
|
||||
- This will allow easier addition of new sources (e.g., local DLNA, generic M3U playlists) without touching the core BMX handlers.
|
||||
|
||||
## 5. Summary
|
||||
While our Go project provides the most complete technical coverage of SoundTouch hardware and commercial services, OpenCloudTouch sets a higher standard for **user onboarding** and **service resilience** for community-driven content. Integrating a setup wizard and a more robust radio backend would make our project significantly more accessible and reliable.
|
||||
+3
-2
@@ -8,7 +8,7 @@ Welcome to the documentation for the Bose SoundTouch Toolkit. This comprehensive
|
||||
- **[Complete Migration Guide](guides/MIGRATION-GUIDE.md)** - Step-by-step guide from Bose Cloud to local control
|
||||
- **[Getting Started](guides/GETTING-STARTED.md)** - Quick introduction to the toolkit
|
||||
|
||||
### For Existing Users
|
||||
### For Existing Users
|
||||
- **[Cloud Shutdown Survival Guide](guides/SURVIVAL-GUIDE.md)** - Prepare for the May 2026 shutdown
|
||||
- **[SoundTouch Service Guide](guides/SOUNDTOUCH-SERVICE.md)** - Advanced service configuration
|
||||
|
||||
@@ -17,7 +17,7 @@ Welcome to the documentation for the Bose SoundTouch Toolkit. This comprehensive
|
||||
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
|
||||
### 2. **Technical Reference** - For developers and advanced configuration
|
||||
### 3. **Concept Documentation** - For contributors and system architects
|
||||
|
||||
## 🗂 Documentation Structure
|
||||
@@ -47,6 +47,7 @@ The documentation is organized into three main categories:
|
||||
|
||||
### API Documentation
|
||||
- [API Endpoints](reference/API-ENDPOINTS.md) - REST API reference
|
||||
- [Spotify Account Addition](reference/spotify-account-addition.md) - Technical requests for Spotify
|
||||
- [WebSocket Events](reference/WEBSOCKET-EVENTS.md) - Real-time events
|
||||
- [Zone Management](reference/ZONE-MANAGEMENT.md) - Multi-room control
|
||||
- [Preset Management](reference/PRESET-MANAGEMENT.md) - Preset operations
|
||||
|
||||
@@ -9,6 +9,7 @@
|
||||
* [Getting Started](guides/GETTING-STARTED.md)
|
||||
* [SoundTouch Service](guides/SOUNDTOUCH-SERVICE.md)
|
||||
* [Initial Device Setup](guides/DEVICE-INITIAL-SETUP.md)
|
||||
* [Device Setup Flow](DEVICE-SETUP.md)
|
||||
* [MAC Address Mapping](guides/MAC-ADDRESS-MAPPING.md)
|
||||
* [HTTPS Setup](guides/HTTPS-SETUP.md)
|
||||
* [Deployment](guides/DEPLOYMENT.md)
|
||||
@@ -28,6 +29,7 @@
|
||||
## Technical Reference
|
||||
* [API Cookbook](reference/API-COOKBOOK.md)
|
||||
* [API Endpoints](reference/API-ENDPOINTS.md)
|
||||
* [Spotify Account Addition](reference/spotify-account-addition.md)
|
||||
* [Cloud API Emulation](reference/CLOUD-API.md)
|
||||
* [System Endpoints](reference/SYSTEM-ENDPOINTS.md)
|
||||
* [Speaker Endpoint](reference/SPEAKER-ENDPOINT.md)
|
||||
@@ -56,12 +58,16 @@
|
||||
* [Wiki API Comparison](analysis/WIKI-COMPARISON.md)
|
||||
* [IoT Config Summary](analysis/IOT-CONFIG-SUMMARY.md)
|
||||
* [IoT Configuration Analysis](analysis/IOT-CONFIGURATION-ANALYSIS.md)
|
||||
* [Bose Lab Runbook](analysis/BOSE-LAB-RUNBOOK.md)
|
||||
* [Missing Routes Spotify](analysis/MISSING-ROUTES-SPOTIFY.md)
|
||||
|
||||
## Parity Analysis
|
||||
* [Parity Improvements](PARITY-IMPROVEMENTS.md)
|
||||
* [Parity SoundCork](PARITY-SOUNDCORK.md)
|
||||
* [Parity OpenCloudTouch](PARITY-OPENCLOUDTOUCH.md)
|
||||
|
||||
## Appendix (Other Documents)
|
||||
* [External Services Abstraction](EXTERNAL-SERVICES-ABSTRACTION.md)
|
||||
* [API Navigation Reference](API-NAVIGATION-REFERENCE.md)
|
||||
* [Claude Instructions](CLAUDE.md)
|
||||
* [Content Selection Implementation](CONTENT-SELECTION-IMPLEMENTATION.md)
|
||||
|
||||
@@ -0,0 +1,423 @@
|
||||
# Bose SoundTouch – Traffic Analysis Runbook
|
||||
|
||||
> **Goal:** Set up a Raspberry Pi as a transparent access point to fully observe the traffic of the Bose SoundTouch app – specifically the pairing flow with the Bose Cloud. This serves as a basis for later reverse engineering / simulation of the cloud endpoints.
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
| Component | Details |
|
||||
|--------------------|------------------------------------------------------------|
|
||||
| Raspberry Pi | Pi 3 or newer, Raspberry Pi OS (Bullseye or newer) |
|
||||
| Network interfaces | `eth0` → LAN cable to FritzBox, `wlan0` → own Access Point |
|
||||
| FritzBox | Unchanged, assigns an IP to the Pi via DHCP on eth0 |
|
||||
| Custom DNS Server | Already present, incl. custom CA certificate |
|
||||
| Phone | Android, connects to the Pi's Wi-Fi |
|
||||
|
||||
### Network Architecture
|
||||
|
||||
```
|
||||
Internet
|
||||
↓
|
||||
FritzBox (existing, unchanged)
|
||||
↓ LAN cable (eth0)
|
||||
Raspberry Pi
|
||||
├── DNS Server → selective logging / redirection
|
||||
├── hostapd → custom Wi-Fi Access Point ("Bose-Lab")
|
||||
├── dnsmasq → DHCP for clients, DNS to custom server
|
||||
├── iptables → NAT, Forwarding eth0 ↔ wlan0
|
||||
├── tcpdump → full traffic capture
|
||||
└── (optional) mitmproxy → HTTPS decryption
|
||||
↓ Wi-Fi ("Bose-Lab")
|
||||
Android Phone
|
||||
└── Bose SoundTouch App
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 1 – Install Packages
|
||||
|
||||
```bash
|
||||
sudo apt update && sudo apt install -y \
|
||||
hostapd \ # Wi-Fi Access Point daemon
|
||||
dnsmasq \ # DHCP + DNS forwarding
|
||||
iptables \ # NAT / firewall / forwarding
|
||||
iptables-persistent \ # Save rules across reboots
|
||||
tcpdump \ # Packet capture at all levels
|
||||
wireshark-common # tshark CLI (optional, for live analysis)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 2 – Enable IP Forwarding
|
||||
|
||||
The Pi must forward packets between `wlan0` (phone) and `eth0` (FritzBox).
|
||||
|
||||
```bash
|
||||
# Active immediately (no reboot required)
|
||||
sudo sysctl -w net.ipv4.ip_forward=1
|
||||
|
||||
# Permanent (survives reboots)
|
||||
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 3 – Static IP on wlan0
|
||||
|
||||
`wlan0` gets a fixed IP – this is the gateway for the phone.
|
||||
|
||||
```bash
|
||||
# Append to /etc/dhcpcd.conf
|
||||
sudo tee -a /etc/dhcpcd.conf << 'EOF'
|
||||
|
||||
interface wlan0
|
||||
static ip_address=192.168.10.1/24
|
||||
nohook wpa_supplicant # wlan0 becomes AP, not Wi-Fi client
|
||||
EOF
|
||||
|
||||
sudo systemctl restart dhcpcd
|
||||
```
|
||||
|
||||
**Verify:**
|
||||
```bash
|
||||
ip addr show wlan0
|
||||
# Expected: inet 192.168.10.1/24
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 4 – hostapd (Access Point)
|
||||
|
||||
```bash
|
||||
sudo tee /etc/hostapd/hostapd.conf << 'EOF'
|
||||
interface=wlan0
|
||||
driver=nl80211
|
||||
ssid=Bose-Lab # Wi-Fi name – phone connects here
|
||||
hw_mode=g
|
||||
channel=6
|
||||
wmm_enabled=0
|
||||
auth_algs=1
|
||||
wpa=2
|
||||
wpa_passphrase=secret123 # Adjust password
|
||||
wpa_key_mgmt=WPA-PSK
|
||||
wpa_pairwise=CCMP
|
||||
EOF
|
||||
|
||||
# Enter config path
|
||||
sudo sed -i \
|
||||
's|#DAEMON_CONF=""|DAEMON_CONF="/etc/hostapd/hostapd.conf"|' \
|
||||
/etc/default/hostapd
|
||||
|
||||
sudo systemctl unmask hostapd
|
||||
sudo systemctl enable --now hostapd
|
||||
```
|
||||
|
||||
**Verify:**
|
||||
```bash
|
||||
sudo systemctl status hostapd
|
||||
# Expected: active (running)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 5 – dnsmasq (DHCP + DNS)
|
||||
|
||||
dnsmasq gives the phone an IP and forwards DNS queries to the custom DNS server.
|
||||
|
||||
```bash
|
||||
# Back up original config
|
||||
sudo mv /etc/dnsmasq.conf /etc/dnsmasq.conf.bak
|
||||
|
||||
sudo tee /etc/dnsmasq.conf << 'EOF'
|
||||
interface=wlan0 # Only listen on AP interface
|
||||
dhcp-range=192.168.10.100,192.168.10.200,24h # IP pool for clients
|
||||
dhcp-option=3,192.168.10.1 # Gateway = Pi
|
||||
dhcp-option=6,192.168.10.1 # DNS = Pi (custom DNS server)
|
||||
|
||||
# DNS Upstream: custom server on localhost (adjust port if necessary)
|
||||
server=127.0.0.1#5353 # Example: custom server on port 5353
|
||||
# Alternatively: server=1.1.1.1 if DNS server runs directly on port 53
|
||||
|
||||
# Log all DNS queries (for initial analysis)
|
||||
log-queries
|
||||
log-facility=/var/log/dnsmasq.log
|
||||
EOF
|
||||
|
||||
sudo systemctl restart dnsmasq
|
||||
```
|
||||
|
||||
**Observe DNS log live:**
|
||||
```bash
|
||||
sudo tail -f /var/log/dnsmasq.log
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 6 – NAT and Forwarding (iptables)
|
||||
|
||||
The Pi routes the phone's traffic to the FritzBox and back.
|
||||
|
||||
```bash
|
||||
# NAT: outgoing packets get the Pi's IP (eth0)
|
||||
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
|
||||
|
||||
# Forwarding: Phone → Internet
|
||||
sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT
|
||||
|
||||
# Forwarding: Responses back to the phone
|
||||
sudo iptables -A FORWARD -i eth0 -o wlan0 \
|
||||
-m state --state RELATED,ESTABLISHED -j ACCEPT
|
||||
|
||||
# Save rules permanently (iptables-persistent)
|
||||
sudo netfilter-persistent save
|
||||
```
|
||||
|
||||
**Verify:**
|
||||
```bash
|
||||
sudo iptables -t nat -L -n -v
|
||||
# Expected: MASQUERADE rule on POSTROUTING for eth0
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 7 – Install Custom CA Certificate on the Phone
|
||||
|
||||
Since a custom DNS server with a custom CA certificate is used, it must be trusted on the phone – otherwise, the app will block HTTPS connections to redirected domains.
|
||||
|
||||
### Copy CA Certificate to the Pi (if not already there)
|
||||
|
||||
```bash
|
||||
# Certificate is located e.g. at /etc/my-dns-ca/ca.crt
|
||||
# Temporarily make reachable via HTTP for easy download:
|
||||
cd /etc/my-dns-ca/
|
||||
python3 -m http.server 8080
|
||||
# → Reachable at http://192.168.10.1:8080/ca.crt
|
||||
```
|
||||
|
||||
### Install on Android
|
||||
|
||||
1. Connect phone to `Bose-Lab`
|
||||
2. Open browser → `http://192.168.10.1:8080/ca.crt`
|
||||
3. Download certificate
|
||||
4. **Settings → Security → Credentials → Install CA Certificate**
|
||||
5. Select certificate and confirm
|
||||
|
||||
> **Note:** Android distinguishes between system CAs and user CAs. User-installed CAs are accepted by many apps, but apps with certificate pinning (hardcoded certificate hashes) ignore them. Whether Bose uses pinning will be visible in the capture (Connection Reset after TLS ClientHello).
|
||||
|
||||
### Android 14+ Special Case
|
||||
|
||||
From Android 14 onwards, apps do not trust user CAs by default unless explicitly declared in the manifest. If the Bose app rejects the CA certificate:
|
||||
|
||||
```bash
|
||||
# Option A: Root + Magisk module "MagiskTrustUserCerts"
|
||||
# → moves user CAs to the system store
|
||||
|
||||
# Option B: Root + manually copy to system CA directory
|
||||
adb push ca.crt /system/etc/security/cacerts/
|
||||
adb shell chmod 644 /system/etc/security/cacerts/ca.crt
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 8 – Capture Traffic
|
||||
|
||||
### All at once (recommended)
|
||||
|
||||
```bash
|
||||
# Full capture of all protocols on wlan0
|
||||
# Filename with timestamp for multiple sessions
|
||||
sudo tcpdump -i wlan0 \
|
||||
-w /tmp/bose-$(date +%Y%m%d-%H%M%S).pcap \
|
||||
-s 0 # full packet length (no truncation)
|
||||
|
||||
# End session: Ctrl+C
|
||||
```
|
||||
|
||||
### Targeted by protocol
|
||||
|
||||
```bash
|
||||
# DNS only (Port 53) – shows if app uses standard DNS
|
||||
sudo tcpdump -i wlan0 -n port 53
|
||||
|
||||
# HTTPS only – TLS connections to Bose Cloud
|
||||
sudo tcpdump -i wlan0 -n 'tcp port 443'
|
||||
|
||||
# mDNS (ZeroConf) – device discovery in LAN
|
||||
# Multicast group 224.0.0.1, Port 5353
|
||||
sudo tcpdump -i wlan0 -n 'udp port 5353'
|
||||
|
||||
# SSDP/UPnP – alternative device discovery
|
||||
sudo tcpdump -i wlan0 -n 'udp port 1900'
|
||||
|
||||
# Everything except DNS (reduces noise)
|
||||
sudo tcpdump -i wlan0 -n 'not port 53' -w /tmp/bose-nodns.pcap
|
||||
|
||||
# Traffic of a specific host only (filter by phone IP)
|
||||
# Read phone IP from dnsmasq.leases beforehand (see below)
|
||||
sudo tcpdump -i wlan0 -n host 192.168.10.101
|
||||
```
|
||||
|
||||
### Read SNI from TLS Traffic (without decryption)
|
||||
|
||||
```bash
|
||||
# Extract domains from TLS ClientHello (SNI is unencrypted)
|
||||
sudo tcpdump -i wlan0 -n 'tcp port 443' -A 2>/dev/null \
|
||||
| grep -oP '(?<=\x00)([a-zA-Z0-9.-]+\.(?:com|net|io|cloud|bose\.com))'
|
||||
```
|
||||
|
||||
### Readable mDNS Announcements output
|
||||
|
||||
```bash
|
||||
# tshark decodes mDNS directly
|
||||
sudo tshark -i wlan0 -f 'udp port 5353' -T fields \
|
||||
-e dns.qry.name \
|
||||
-e dns.resp.name \
|
||||
-e dns.a
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 9 – Analysis with Wireshark (on PC)
|
||||
|
||||
Transfer `.pcap` files from the Pi to the PC:
|
||||
|
||||
```bash
|
||||
# From the PC (scp)
|
||||
scp pi@192.168.10.1:/tmp/bose-*.pcap ~/Desktop/
|
||||
```
|
||||
|
||||
**Important Wireshark Filters:**
|
||||
|
||||
```
|
||||
# DNS only
|
||||
dns
|
||||
|
||||
# HTTPS only
|
||||
tcp.port == 443
|
||||
|
||||
# WebSocket connections (HTTP Upgrade)
|
||||
websocket
|
||||
|
||||
# mDNS
|
||||
mdns
|
||||
|
||||
# TLS Handshakes (SNI visible)
|
||||
tls.handshake.extensions_server_name
|
||||
|
||||
# Traffic of a specific domain (resolve by IP)
|
||||
http.host contains "bose"
|
||||
|
||||
# WebSocket frames
|
||||
websocket.payload
|
||||
```
|
||||
|
||||
> **Tip:** Wireshark decodes WebSocket frames automatically if it sees the HTTP Upgrade handshake in the same capture. For the pairing flow: filtering for `tls.handshake.extensions_server_name` shows all domains the app contacts, even without decryption.
|
||||
|
||||
---
|
||||
|
||||
## Step 10 – mitmproxy (optional, for HTTPS content)
|
||||
|
||||
Only useful if the CA certificate on the phone is trusted and no certificate pinning is active.
|
||||
|
||||
```bash
|
||||
sudo apt install -y mitmproxy
|
||||
|
||||
# Transparent proxy on port 8080
|
||||
mitmproxy --mode transparent --listen-port 8080
|
||||
|
||||
# Alternatively: mitmdump for automatic logging to file
|
||||
mitmdump --mode transparent --listen-port 8080 \
|
||||
-w /tmp/bose-https.mitm
|
||||
```
|
||||
|
||||
**iptables rule: redirect HTTPS traffic to mitmproxy**
|
||||
|
||||
```bash
|
||||
# Only for wlan0 traffic (phone) → Port 443 → mitmproxy on 8080
|
||||
sudo iptables -t nat -A PREROUTING \
|
||||
-i wlan0 -p tcp --dport 443 \
|
||||
-j REDIRECT --to-port 8080
|
||||
```
|
||||
|
||||
**Remove rule when no longer needed:**
|
||||
|
||||
```bash
|
||||
sudo iptables -t nat -D PREROUTING \
|
||||
-i wlan0 -p tcp --dport 443 \
|
||||
-j REDIRECT --to-port 8080
|
||||
```
|
||||
|
||||
> **Detecting Certificate Pinning:** If the app immediately disconnects after mitmproxy redirection (connection reset directly after TLS ClientHello), pinning is active. In this case, Frida + root is needed to patch the pinning.
|
||||
|
||||
---
|
||||
|
||||
## Helper Commands / Troubleshooting
|
||||
|
||||
```bash
|
||||
# Which IPs did the phone receive?
|
||||
cat /var/lib/misc/dnsmasq.leases
|
||||
|
||||
# Is the access point active?
|
||||
sudo systemctl status hostapd
|
||||
|
||||
# Is dnsmasq active?
|
||||
sudo systemctl status dnsmasq
|
||||
|
||||
# Check interfaces and IPs
|
||||
ip addr show
|
||||
|
||||
# Check routing table
|
||||
ip route show
|
||||
|
||||
# Show active iptables rules
|
||||
sudo iptables -L -n -v
|
||||
sudo iptables -t nat -L -n -v
|
||||
|
||||
# All running tcpdump processes
|
||||
pgrep -a tcpdump
|
||||
|
||||
# Test the Pi's own DNS resolution
|
||||
dig @127.0.0.1 -p 5353 global.api.bose.io
|
||||
|
||||
# Check network connectivity from the phone (from the Pi)
|
||||
ping 192.168.10.101 # Phone IP from dnsmasq.leases
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Restart Sequence
|
||||
|
||||
After a Pi reboot, everything should come up automatically. If not:
|
||||
|
||||
```bash
|
||||
sudo systemctl start dhcpcd
|
||||
sudo systemctl start hostapd
|
||||
sudo systemctl start dnsmasq
|
||||
sudo netfilter-persistent reload
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What to Expect
|
||||
|
||||
| Protocol | Port | Tool | Visibility |
|
||||
|----------------------|------------|--------------------------|------------------------------------------------|
|
||||
| DNS (Standard) | UDP 53 | tcpdump, dnsmasq log | Full, plaintext |
|
||||
| HTTPS / REST | TCP 443 | tcpdump (SNI), mitmproxy | SNI without decryption, content with mitmproxy |
|
||||
| WebSockets | TCP 443/80 | Wireshark | Frames decoded if TLS is broken |
|
||||
| mDNS / ZeroConf | UDP 5353 | tcpdump, tshark | Full, plaintext |
|
||||
| SSDP / UPnP | UDP 1900 | tcpdump | Full, plaintext |
|
||||
| SoundTouch local API | TCP 8090 | tcpdump | Full, plaintext (no TLS) |
|
||||
|
||||
> **Expectation for Bose SoundTouch:** The app likely uses standard DNS (older app generation), REST/HTTPS for the pairing flow with the cloud, WebSockets for push events from the device, and mDNS for local device discovery. The local device API on port 8090 is HTTP without TLS – this traffic is always readable.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps After Analysis
|
||||
|
||||
1. Extract domains from DNS log and SNI → List of all Bose endpoints
|
||||
2. HTTP methods and paths from mitmproxy log → Reconstruct API structure
|
||||
3. Document auth flow (OAuth2? Proprietary? Token format?)
|
||||
4. Build a minimal mock server simulating the critical endpoints
|
||||
5. Testing: App against mock server → does pairing work offline?
|
||||
@@ -0,0 +1,43 @@
|
||||
# Spotify Account Addition Implementation Status
|
||||
|
||||
To fully replace Bose cloud services for the Spotify account addition flow in the "Stockholm" SoundTouch application, the following routes have been implemented in the `soundtouch-service`:
|
||||
|
||||
## 1. OAuth Token Exchange (Bose Cloud)
|
||||
|
||||
The Stockholm background worker (in `worker_common.js` and `spotify_worker.js`) performs a token exchange using an authorization code.
|
||||
|
||||
* **Route**: `POST /oauth/account/{account}/music/musicprovider/{sourceID}/token/cs`
|
||||
* **Purpose**: To exchange the Spotify authorization code for a Bose-mediated token.
|
||||
* **Implementation**: `HandleBoseAccountToken` in `pkg/service/handlers/handlers_oauth.go`.
|
||||
* **Registration**: Registered in `cmd/soundtouch-service/main.go` under the `/oauth` route group.
|
||||
|
||||
## 2. Cloud Source Registration (Marge Service)
|
||||
|
||||
The SoundTouch application registers a new music source (e.g., Spotify) with the Bose cloud profile.
|
||||
|
||||
* **Route**: `POST /streaming/account/{account}/source`
|
||||
* **Purpose**: To add the new source (username, credentials, display name) to the user's emulated cloud profile.
|
||||
* **Implementation**: `HandleMargeAddSource` in `pkg/service/handlers/handlers_marge.go`.
|
||||
* **Registration**: Registered in `cmd/soundtouch-service/main.go` under the `/streaming` route group.
|
||||
* **Payload Format**: XML `application/vnd.bose.streaming-v1.1+xml` containing `<source>` with `<username>`, `<sourceproviderid>`, and `<credential type="token_version_3">`.
|
||||
|
||||
## 3. Redirect Handling (Browser to App)
|
||||
|
||||
The `soundtouch://` deep link redirect URI is handled by the management interface which provides the OAuth callback.
|
||||
|
||||
* **Callback Route**: `GET /mgmt/spotify/callback`
|
||||
* **Implementation**: `HandleMgmtSpotifyCallback` in `pkg/service/handlers/handlers_mgmt.go`.
|
||||
* **Confirmation Route**: `POST /mgmt/spotify/confirm` (used by mobile apps for deep-link codes).
|
||||
* **Implementation**: `HandleMgmtSpotifyConfirm` in `pkg/service/handlers/handlers_mgmt.go`.
|
||||
|
||||
## Implementation Details
|
||||
|
||||
1. **Marge Add Source**:
|
||||
* `HandleMargeAddSource` in `pkg/service/handlers/handlers_marge.go` parses the incoming XML and persists the new source to the `DataStore` for the corresponding account.
|
||||
|
||||
2. **OAuth Account Token Exchange**:
|
||||
* `HandleBoseAccountToken` in `pkg/service/handlers/handlers_oauth.go` supports the `/oauth/account/.../token/cs` path.
|
||||
* It responds with a JSON payload including `access_token` and `token_type` "Bearer" after exchanging the code via `ExchangeCodeAndStore`.
|
||||
|
||||
3. **Router Registration**:
|
||||
* These paths are registered in `cmd/soundtouch-service/main.go` within the `/streaming`, `/oauth`, and `/mgmt` route blocks.
|
||||
@@ -0,0 +1,184 @@
|
||||
# Spotify Account Addition Technical Reference
|
||||
|
||||
This document details the exact network requests performed by the Bose SoundTouch "Stockholm" application and the SoundTouch speaker when adding a new Spotify account. This information is based on analysis of the Stockholm firmware version `27.0.13-4277-8963611`.
|
||||
|
||||
## Flow Overview
|
||||
|
||||
1. **User Authorization Initiation**: The app opens the system browser to Spotify's authorization page.
|
||||
2. **Redirect Handling**: After authorization, Spotify redirects back to the app via a custom URI scheme, delivering an authorization `code`.
|
||||
3. **OAuth Token Exchange**: The app sends this `code` to the background worker, which exchanges it for a Bose-mediated token.
|
||||
4. **Cloud Source Registration**: The app registers the Spotify account as a "source" in the user's Bose Cloud (Marge) profile.
|
||||
5. **Local Device Sync**: The app notifies the local SoundTouch speaker about the new source, which then updates its internal configuration.
|
||||
|
||||
---
|
||||
|
||||
## 0. User Authorization Initiation
|
||||
|
||||
The process begins in the Stockholm UI when the user selects Spotify to add a new account.
|
||||
|
||||
### Request Details (App to Browser)
|
||||
- **Action**: Open System Browser
|
||||
- **Base URL**: `[SPOTIFY_AUTH_URL]` (e.g., `https://accounts.spotify.com/authorize`)
|
||||
- **Query Parameters**:
|
||||
- `client_id`: Bose Spotify Client ID
|
||||
- `response_type`: `code`
|
||||
- `redirect_uri`: `http://localhost` (often used as a placeholder or specifically handled by the app's internal webview/proxy)
|
||||
- `scope`: `user-read-private user-read-email ...`
|
||||
- `state`: A base64-encoded JSON object containing metadata, e.g., `{"service": "SPOTIFY"}`.
|
||||
|
||||
### Redirect (Browser to App)
|
||||
Upon successful login and authorization, Spotify redirects the browser to a URL that the SoundTouch app intercepts.
|
||||
|
||||
- **URL Format**: `soundtouch://bose/musicservice/spotify/login?code=[AUTH_CODE]&state=[STATE]`
|
||||
- **App Action**: The `UIMain` component (in `ui_main.js`) handles this "deep link". It extracts the `code` from the query parameters and prepares to send it to the background worker.
|
||||
|
||||
---
|
||||
|
||||
## 1. OAuth Token Exchange (Bose Cloud)
|
||||
|
||||
After the UI intercepts the redirect and extracts the `code`, it sends a `createOAuthAccountRequest` to the background `SpotifyWorker`. The worker then performs the exchange for a Bose-mediated token.
|
||||
|
||||
### What is a "Bose-mediated token"?
|
||||
The "Bose-mediated token" is a token issued by the Bose OAuth proxy. When the app (or device) requests a token via `oauth.streaming.bose.com`, Bose's service performs the actual OAuth2 exchange with Spotify.
|
||||
|
||||
- **It is not directly a Spotify refresh token**: Instead, it is a Bose-issued token that *represents* the underlying Spotify session.
|
||||
- **Token Version 3**: Modern firmware uses `token_version_3`, which signifies that the device doesn't store the raw Spotify tokens but instead uses a Bose-specific "secret" that the Bose Cloud uses to fetch fresh Spotify access tokens on the device's behalf.
|
||||
- **Access vs Refresh**: The initial response from the `.../token/cs` endpoint typically contains an `access_token` (valid for ~1 hour) and a `token_type: "Bearer"`. The Bose cloud service manages the persistent refresh token internally.
|
||||
|
||||
### Internal Message (UI to Worker)
|
||||
- **Message Type**: `createOAuthAccountRequest`
|
||||
- **Payload**:
|
||||
```json
|
||||
{
|
||||
"source": "SPOTIFY",
|
||||
"code": "[AUTH_CODE_FROM_REDIRECT]",
|
||||
"credentialType": "token_version_3"
|
||||
}
|
||||
```
|
||||
|
||||
### Outgoing Request (Worker to Bose OAuth Proxy)
|
||||
- **Endpoint**: `https://oauth.streaming.bose.com/oauth/account/[ACCOUNT_ID]/music/musicprovider/15/token/cs`
|
||||
- **Method**: `POST`
|
||||
- **Headers**:
|
||||
- `Content-Type: application/json`
|
||||
- `Accept: application/json`
|
||||
- `Authorization: Bearer [SESSION_TOKEN]` (The user's Bose account session token)
|
||||
|
||||
### Payload (JSON)
|
||||
```json
|
||||
{
|
||||
"grant_type": "authorization_code",
|
||||
"code": "[AUTH_CODE_FROM_SPOTIFY]",
|
||||
"redirect_uri": "http://localhost"
|
||||
}
|
||||
```
|
||||
|
||||
### curl Example
|
||||
```bash
|
||||
curl -X POST "https://oauth.streaming.bose.com/oauth/account/[ACCOUNT_ID]/music/musicprovider/15/token/cs" \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Authorization: Bearer [SESSION_TOKEN]" \
|
||||
-d '{
|
||||
"grant_type": "authorization_code",
|
||||
"code": "[AUTH_CODE_FROM_SPOTIFY]",
|
||||
"redirect_uri": "http://localhost"
|
||||
}'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Cloud Source Registration (Marge)
|
||||
|
||||
The app now registers the Spotify account with the Bose "Marge" service. This makes the source available across all devices linked to the same Bose account.
|
||||
|
||||
### Request Details
|
||||
- **Endpoint**: `https://streaming.bose.com/streaming/account/[ACCOUNT_ID]/source`
|
||||
- **Method**: `POST`
|
||||
- **Headers**:
|
||||
- `Content-Type: application/vnd.bose.streaming-v1.1+xml`
|
||||
- `Authorization: [MARGE_TOKEN]`
|
||||
- `GUID: [DEVICE_GUID]`
|
||||
- `ClientType: Stockholm`
|
||||
|
||||
### Payload (XML)
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<source>
|
||||
<username>[SPOTIFY_USER_ID]</username>
|
||||
<sourceproviderid>15</sourceproviderid>
|
||||
<credential type="token_version_3">[SECRET_TOKEN_OBTAINED_IN_STEP_1]</credential>
|
||||
<sourcename>[DISPLAY_NAME_E_G_EMAIL]</sourcename>
|
||||
</source>
|
||||
```
|
||||
|
||||
### curl Example
|
||||
```bash
|
||||
curl -X POST "https://streaming.bose.com/streaming/account/[ACCOUNT_ID]/source" \
|
||||
-H "Content-Type: application/vnd.bose.streaming-v1.1+xml" \
|
||||
-H "Authorization: [MARGE_TOKEN]" \
|
||||
-d '<?xml version="1.0" encoding="UTF-8"?><source><username>[USER]</username><sourceproviderid>15</sourceproviderid><credential type="token_version_3">[TOKEN]</credential><sourcename>[NAME]</sourcename></source>'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Local Device Notification (LISA API)
|
||||
|
||||
The app notifies the physical SoundTouch speaker about the new source. This is usually done via the device's management API on port 8090.
|
||||
|
||||
### Request Details
|
||||
- **Endpoint**: `http://[DEVICE_IP]:8090/setMusicServiceOAuthAccount`
|
||||
- **Method**: `POST`
|
||||
|
||||
### Payload (XML)
|
||||
```xml
|
||||
<OAuthCredentials source="SPOTIFY" displayName="[DISPLAY_NAME]">
|
||||
<user>[SPOTIFY_USER_ID]</user>
|
||||
<code>[AUTH_CODE_OR_TOKEN]</code>
|
||||
<version>token_version_3</version>
|
||||
</OAuthCredentials>
|
||||
```
|
||||
|
||||
**Note**: In some cases, the app sends a wrapped message format if communicating over WebSockets:
|
||||
```xml
|
||||
<msg>
|
||||
<header deviceID="[DEVICE_UID]" url="setMusicServiceOAuthAccount" method="POST">
|
||||
<request requestID="1">
|
||||
<info type="new" />
|
||||
<sourceItem source="SPOTIFY" />
|
||||
</request>
|
||||
</header>
|
||||
<body>
|
||||
<OAuthCredentials source="SPOTIFY" displayName="[NAME]">
|
||||
<user>[USER]</user>
|
||||
<code>[TOKEN]</code>
|
||||
<version>token_version_3</version>
|
||||
</OAuthCredentials>
|
||||
</body>
|
||||
</msg>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Placeholders and Constants
|
||||
|
||||
| Placeholder | Description |
|
||||
|:------------------|:----------------------------------------------------|
|
||||
| `[ACCOUNT_ID]` | The internal Bose account ID (UUID). |
|
||||
| `[SESSION_TOKEN]` | Temporary token from Bose login. |
|
||||
| `[MARGE_TOKEN]` | Persistent authorization token for Marge services. |
|
||||
| `[DEVICE_GUID]` | Unique identifier for the controller app instance. |
|
||||
| `[DEVICE_IP]` | Local IP address of the SoundTouch speaker. |
|
||||
| `15` | Constant `sourceproviderid` for Spotify. |
|
||||
| `token_version_3` | Credential type for modern OAuth2 Spotify accounts. |
|
||||
|
||||
---
|
||||
|
||||
## Resulting Persistence
|
||||
|
||||
Once these requests succeed, the device updates its `/mnt/nv/BoseApp-Persistence/1/Sources.xml` file:
|
||||
|
||||
```xml
|
||||
<source displayName="user@example.com" secret="[SECRET_BLOB]" secretType="token_version_3">
|
||||
<sourceKey type="SPOTIFY" account="user" />
|
||||
</source>
|
||||
```
|
||||
Reference in New Issue
Block a user