[icecast] playlist streams

[Todd Poston]

Adon Irani wrote:
------------------
however, if you are using the fileserve option ; you only need to
generate a playlist that links to these songs . however, this again
opens up security issues of direct access to the songs ( perhaps someone
else can speak about this .. I'm not sure how this all works )
------------------

(Long: semi-detailed explanation of how to do secure file-serving below
- does not involve icecast)

It is fairly simple (and known since the beginning of CGI) to restrict
access to files served to the web from a webserver.  Webservers
generally provide some built-in security that usually leverages the file
security of the operating system.  Many times, that security is not
dynamic enough for an application.  There are hundreds of examples (if
not more), to "serve" files dynamically.

Basically, if you want to go the fileserve route, all you have to do is
to create a script or executable (depending on your choice of dev
platforms, operating system and webserver) that takes parameters (query
string (GET), form data (POST), or session variables) that tell the
script which "file" (read: MP3 or ogg) to send to the client.  That
script can perform the necessary authorization to determine if this
client is allowed to download/stream this file.

It's simple, even MS provides source code to do this.  The way it works
is you have this script that can take parameters and return data (it can
be perl, php, asp, cgi, whatever).  Let's say it is located at 
http://localhost/getFile.asp.

You pass it the following data: 
File=waynefrigginnewton.ogg.

getFile.asp opens the waynefrigginnewton.ogg file and sends every byte
it reads to the Response, and thus the client (Winamp).

The actual ogg file is located in a private directory that is not
accessible from the published directories of your webserver.  Thus no
one can actually download the file directly, they must go thru your
script to get it.  That will at least make it a little harder for people
to download your songs.

The way to take it a step further is to add authorization (which may
include authentication) in your script.  This can be things like 1) has
this client already downloaded this song 2), how long has this client
been connected to my server (when did their session start?) 3), how many
other songs has this client downloaded, etc.  You could also require a
usr/pwd as the data passed to the script.

Probably the best, and most used method is to require users to go to
your website first (this lets you track their session)..they may or may
not "log in" to your site, but you still know who they are uniquely.
You can then provide link(s) to your (static or generated) .m3u or .pls
directly.  If you generated the m3u file, you can include the unique ID
of the client in the links.  So your m3u file might look like:

http://mydomain.com/getFile.asp?ID=ASDF1234QWER1234&file=waynefrigginnew
ton.ogg
http://mydomain.com/getFile.asp?ID=ASDF1234QWER1234&file=britneyfriggins
pears.ogg
http://mydomain.com/getFile.asp?ID=ASDF1234QWER1234&file=frankfrigginsin
atra.ogg
http://mydomain.com/getFile.asp?ID=ASDF1234QWER1234&file=foofrigginfight
ers.ogg

Your getFile script then just tracks the client by the "ID" value and
their webserver session to determine what they are allowed to "Stream"
from your script.  If they ever just go straight to your getFile script
on your webserver but have an invalid or expired ID they get nothing.
As you can see you can get quite innovative on how you handle this and
what you choose to let your clients do.  It all depends on how much
development you want to do to handle the authorization.

This is done ALL the time on the web to restrict access to files like
images (pr0n) or pdf's that may contain sensitive data that you want to
provide on the web, but don't necessarily want anyone to be able to get
to unless they go thru the proper steps.  And it may be prohibitive to
use just the OS's file system security due to a number of reasons like:
hosted sites (it ain't your box so you can't control file security) or
you cannot dynamically generate usrs/passwords and restrict
directory/file access, etc.

The biggest hurdle (which isn't much) is to make sure your script has
read access to the unpublished directory that contains the files you
want to stream.
The downside to this approach, and the reason it isn't used more often
for simple things, is that there is a performance hit by doing the file
I/O this way, rather then just letting the webserver do it.

Hope I didn't bore you all to death with this off-topic message.

Todd

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.