Separate admin and stream

This page needs editing. It may contain errors and/or outdated information. I'm trying to separate the main admin and stream.mp3. The idea is that I'll be able to run SlimServer, and have Apache proxy to it's admin interface. Apache will apply SSL and authentication. Meanwhile, clients (such as Winamp et al.) will be able to connect without SSL (which the majority don't seem to support).

I know this is (more or less) possible as-is. I could run the whole admin interface on a server, and just use that for stream.m3, but I think that's a security problem (Basic authentication isn't really enough to secure it!).

Ways to do this:

1) Use Apache to proxy everything. Configure Apache so that stream.mp3 is the only thing available without SSL.

This works fine, except that multiple clients are not supported (and indeed crash SlimServer). All clients funnel through Apache, so Slimserver sees them all as 127.0.0.1, and doesn't properly differentiate them. Also, Apache adds a bit more buffering to the data stream, which while far from disaterous, isn't really ideal.

2) Use a custom proxy to limit connections. I tried writing a bit of Perl to perform the proxy function (as per above). It only allows access to stream.mp3, and only allows one client to connect. Trouble is, it consumes hideous amounts of CPU, and adds buffering to the data stream.

3) Modify Slimserver to accommodate this cunning and devious idea.

I had a look at doing this - I think my Perl is (just about) up to it. Trouble is, I can't find where to start in the source code (much of which is commentless). Anyone know their way around the source enough to give me a couple of pointers? – coofercat

An alternative method (perhaps):

Variant on (1) + (2) above - configure Apache to proxy everything except Slimserver's own ports, but make it \"map\" some of its proxied namespace onto Slimserver's own admin port...

Have a wrapper-script on Apache living in, say /cgi-bin/ called \"slimserver\" that takes the URL it's called with (e.g. https://apacheservername/cgi-bin/slimserver/thingy.html) does a bit of text processing to turn it into \"/thingy.html\" and pass the request straight on to localhost:9000, then to parse the resulting output for HTML and change any URLs of the form \"http://localhost:9000/thingy.html\" back to \"https://apacheservername/cgi-bin/slimserver/thingy.html\". /

Then you lock down access to port 9000 so that localhost has unrestricted access but nobody you don't trust has unrestricted access AND hack the slimserver code to reject requests for anything other than stream.mp3 if it didn't come from localhost. This is pretty crude as well, but works by intercepting the admin traffic, not the streaming traffic, hence leaves the time-critical stuff alone. Disclaimer: I'm new to this Squeezebox stuff, hence I've no idea how the SB sends its signals back to the server, hence the above idea might well secure access too well and prevent that from working.

Personally, the method I use to secure access to my own server is to lock absolutely everything down & firewall it so that only SSH is externally accessible. If I want anything to get through the firewall, I login using SSH from whereever I am and get it to tunnel whatever TCP/IP streams I'm after through the SSH session. If I wanted to put a Squeezebox by my desk at work, and listen to music on my home server, I'd tunnel the Squeezebox TCP ports from my work PC to my home server using SSH, and tell the Squeezebox that the server was my work PC. I've not done this (yet), so there might be all sorts of buffering issues from the SSH encryption etc, but it would be secure...

--Krinly

This is exactly how I do it, it works just fine. Both ports/streams are tunneled via SSH.

--R. Owen

I have another quite clean solution for an apache setup on my Weblog at http://blog.hanno-stock.de/archives/5 .

My solution allows HTTPS access to the web interface and (almost) unrestricted access via HTTP to /stream.mp3. The restriction is that you can only access /stream.mp3 from ip addresses that have successfully logged on to the HTTPS protected interface in the last 30 minutes.

Since almost every browser supports HTTPS and almost every MP3 player supports normal HTTP streaming, you can access your music from almost every computer!

I use mod_python and a very small script. All request handling and authentication is entirely done by Apache - which should make this a very robust solution.

--H. Stock