[icecast] playlist streams

[Ross Levis]

Thanks for the details Todd.  Much appreciated.

Regards,
Ross Levis.

> -----Original Message-----
> From: owner-icecast at xiph.org [mailto:owner-icecast at xiph.org] 
> On Behalf Of Todd Poston
> Sent: Tuesday, 18 March 2003 08:30
> To: icecast at xiph.org
> Subject: RE: [icecast] playlist streams
> 
> 
> 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.
--- >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.