[icecast-dev] Icecast User Login Question

[oddsock]

At 10:21 AM 11/4/2003 -0500, you wrote:
>Scott Manley wrote:
>
>>Actually if you;re interested in integration with some sort of 
>>subscription services then you want as much of the subscription logic to 
>>be external as possible - trust me - I designed a subscription based 
>>system which handled 7 million users (and managed to bankrupt at least 
>>one company ;-)
>>
>>Basically when you get into subscription based streaming you can 
>>potentially end up doing a whole load of database logic, and different 
>>subscription models need different logic, so as much of this wants to be 
>>in external applications. Icecast should concern itself with pushing out 
>>data and not much else, authentication shouldn't be much more than 
>>username/password or ticket based checking. For versatile subscription 
>>engines the ticket generation can be done in whatever backend language 
>>you want.
>
>I understand your point, but the fact of the matter is that many/most 
>sites won't ever serve up to 7million users.  In fact in the context of 
>the original question, which sounds like college radio, the subscriber 
>base may only be local college students, or citizens from the surrounding area.
>
>I happen to setup WXOU's streaming server here at Oakland University a few 
>years ago.  Unfortunately it was disabled when the RIAA sent out all those 
>desist orders a few years ago, and it was never brought back up. In the 
>case of WXOU, the RIAA situation could have been easily handled with an 
>authentication scheme that allowed university affiliates to somehow 
>authenticate to the stream.
>
>My point is, that in many cases, the authorization and authentication 
>scheme may integrate with an already existing user base.  I would suggest 
>that auth hooks such as pam, ldap, and radius be implemented, as well as 
>source IP based auth.  That would be perfect for WXOU, and so I imagine we 
>are not alone.

yes, but basic authorization/authentication is different than 
subscription-based services... Authorization/Authentication services is 
more a simple (is this a valid user), but Subscription-based services are 
more (is this a valid user and do they have enough listening tokens and 
have they maybe bought more tokens while they are listening and want to 
continue their listening session).... I think basic 
authorization/authentication does have a place in icecast2 and there are 
many ways to do it...If I were to do it, I'd do via a simple URL 
call...Someone else might make it access a file or ldap based repository of 
users/passwords... Since most people tend to use icecast2 in a hosted 
environment I think, a URL based authorization scheme makes the most 
sense...but thats just me.. :)

oddsock

<p><p>--- >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-dev-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.