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. I just may implement this in icecast2 when I get some free time. So far looking at the icecast2 source, I find it to be well structured and easy to extend. I was attempting to add delayed connection ability to relay streams a couple weeks ago, and I was able to make some progress in a very short amount of time. I may spend some time on trying to implement this in the next few months. -- Jay --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Sure thats all fine and dandy but i think its more of a secure option for the icecast2 server to handle this internaly than a 3rd party script. <p><p>Dave St John (CEO) Mediacast1.com ----- Original Message ----- From: "Scott Manley" <djsnm@djsnm.com> To: <icecast-dev@xiph.org> Sent: Monday, November 03, 2003 7:14 PM Subject: Re: [icecast-dev] Icecast User Login Question <p>> Heh, you have no idea how messy it can become.> > Anyway, one easy-ish way is to have a script which does all the > authentication and then performs a redirect to the live server. I seem > to remember most media players correctly handled redirects. > > The trick then is to make the redirect link expire over time. > > > > > > > actually, as it turns out, this does make alot of sense, because most > > authentication/subscription logic is going to be fairly complicated and > > needs to be customizable for each "subscription service". adding logic > > to icecast2 to do simple URL calls when listeners connect (the URL call > > validating the user and allowing/denying access) and letting the > > external scripts do all the necessary "subscription logic" is a nice > > easy way to setup a subscription service.... > > > > just my experience :) > > > > oddsock > > > > --- >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@xiph.org'> containing only the word 'unsubscribe' in the body. No subject is needed. > Unsubscribe messages sent to the list will be ignored/filtered. ><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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Dave St John wrote:> Sure thats all fine and dandy but i think its more of a secure option for > the icecast2 server to handle > this internaly than a 3rd party script. >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 ;-) <p>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. Scott Manley --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.