implementing api-driven audio routing: controlling bose soundtouch speakers with nginx reverse proxy and custom authentication middleware

Implementing API-Driven Audio Routing: Controlling Bose SoundTouch Speakers with NGINX Reverse Proxy and Custom Authentication Middleware

Why I worked on this

I wanted to integrate my Bose SoundTouch speakers into my home automation system without exposing them directly to the internet. The Bose speakers have a web API, but it’s not secure by default, and I didn’t want to risk leaving them open to potential attacks. I needed a way to control the speakers programmatically while maintaining security and control over who can access them.

My real setup or context

Here’s what I had:

• Two Bose SoundTouch 300 speakers connected to my local network
• An NGINX server running on a Proxmox VM
• Python 3.9 installed on a Raspberry Pi
• A need to control the speakers from both local devices and remotely (but securely)

I decided to use the bosesoundtouchapi Python library to interact with the speakers and set up an NGINX reverse proxy with custom authentication middleware to secure the API endpoints.

What worked (and why)

Step 1: Installing and Setting Up the Bose SoundTouch API

First, I installed the bosesoundtouchapi library:

python3 -m pip install bosesoundtouchapi

Then, I created a simple Python script to test the API:

from bosesoundtouchapi.soundtouchdiscovery import SoundTouchDiscovery

# Discover all Bose SoundTouch devices on the network
devices = SoundTouchDiscovery.discover()

for device in devices:
    print(f"Found device: {device.name} at {device.host}")

This worked perfectly, and I could see both of my speakers listed with their IP addresses.

Step 2: Creating a Custom API Endpoint

I wanted to create a custom API endpoint that would expose only the functionality I needed. I used Flask to create a simple web server:

from flask import Flask, request, jsonify
from bosesoundtouchapi.soundtouchclient import SoundTouchClient

app = Flask(__name__)

# Replace with your speaker's IP address
SPEAKER_IP = "192.168.1.100"

@app.route('/api/speaker/volume', methods=['POST'])
def set_volume():
    data = request.get_json()
    volume = data.get('volume')

    if volume is None:
        return jsonify({'error': 'Volume not specified'}), 400

    client = SoundTouchClient(SPEAKER_IP)
    client.set_volume(volume)

    return jsonify({'status': 'success'})

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Step 3: Setting Up NGINX Reverse Proxy

I configured NGINX to act as a reverse proxy for my Flask app:

server {
    listen 80;
    server_name speaker-api.example.com;

    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

This allowed me to access the API via http://speaker-api.example.com/api/speaker/volume.

Step 4: Adding Custom Authentication Middleware

To secure the API, I added custom authentication middleware to NGINX:

auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/.htpasswd;

I generated a password file using the following command:

htpasswd -c /etc/nginx/.htpasswd username

Now, accessing the API required a username and password.

What didn’t work

Initially, I tried to use the Bose SoundTouch API directly from my home automation system, but I ran into two problems:

1. Security Concerns: The Bose API doesn’t support authentication, so leaving it exposed on my network was a risk. I needed a way to add a layer of security.

2. CORS Issues: My home automation system runs on a different port, and the Bose API didn’t support CORS. This made it difficult to make requests from my frontend.

The NGINX reverse proxy solved both of these problems by acting as a gateway that I could secure and configure to handle CORS.

Key takeaways

1. Security is crucial: Always add a layer of authentication when exposing APIs, even on your local network.

2. NGINX is versatile: It can act as a reverse proxy, handle authentication, and manage CORS, making it a great tool for securing and exposing APIs.

3. Modularity is key: By creating a custom API endpoint, I could expose only the functionality I needed, reducing the attack surface.

4. Testing is essential: Always test your setup thoroughly to ensure that everything works as expected and that there are no security vulnerabilities.