After reviewing the discussion from early November regarding user authentication and subscription schemes in Icecast, I've been chewing on some ideas to implement this in a flexible way that has benefit to everyone and minimal impact on the core server. Because everyone's subscription/authentication needs are going to differ, it probably is best to keep as much of the auth logic external to the server. In our particular situation, we would simply like to authenticate users to a mountpoint, and it's important that no more than one person can log on at a time using the same username and password pair. We'd like to store our username, password and mount authorization in a MySQL db. What about SOAP (or would this be an RPC)? When a client connects, a SOAP object is sent to the subscription/authorization server containing the username, password and requested mount. The auth server can then process this and return true or false. Then when the client logs off, another object would be sent to note that event. The cool thing about this is that you can write whatever authorization logic you'd like. Icecast just has to send the objects (and get a response when someone is logging on) with no knowledge of how the decision to authenticate or not is made. Or is there better/easier protocol or method to use to get the same effect? I would guess this could also be done with URL calls as well but how would Icecast accept the response? Is this ability built into the httpp library? Any and all suggestions welcome... Thanks - bryan --- >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.
I agree, HTTP response headers would be perfect :) as i have hacked toms shoutcast proxy to work with icecast2 mp3 MySQL/PHP user administration, actualy its so hacked its taken on its own life, but none the less it works rather well with mp3, ogg needs work as winamp doesnt like the response headers for ogg that the php script sends. <p><p><p>Dave St John Mediacast1 Administrator ----- Original Message ----- From: "oddsock" <oddsock@oddsock.org> To: <icecast-dev@xiph.org> Sent: Friday, January 30, 2004 7:55 AM Subject: Re: [icecast-dev] User authentication schemes <p>> At 01:16 PM 1/26/2004, you wrote:> > >What about SOAP (or would this be an RPC)? When a client connects, a SOAP > >object is sent to the subscription/authorization server containing the > >username, password and requested mount. The auth server can then process > >this and return true or false. Then when the client logs off, another > >object would be sent to note that event. The cool thing about this isthat> >you can write whatever authorization logic you'd like. Icecast just hasto> >send the objects (and get a response when someone is logging on) with no > >knowledge of how the decision to authenticate or not is made. Or is there > >better/easier protocol or method to use to get the same effect? > > > >I would guess this could also be done with URL calls as well but howwould> >Icecast accept the response? Is this ability built into the httpplibrary?> this approach is pretty much exactly what I was thinking, although I don't > think SOAP is necessarily the right approach, a simple URL call will > suffice for this...the communication protocol would be fairly > simple...Icecast passed user/pass/mount info via a URL call, and the URL > call must respond with certain specified HTTP response headers indicating > success or failure, and based on those responses icecast would accept or > deny the client. > > the downside is that this would require plaintext users and password being > sent over the wire, although since they are already coming IN using simple > HTTP authentication, this is already being done, so not much different if > you ask me.. > > we have alot of the infrastructure for URL calls already in icecast (dueto> the YP listing code which uses it) and so we can re-use alot of that. > > Mike has also implemented a simpler approach, which is also very usefuland> works the way apache .htpasswd files work. I think supporting both > mechanisms is a good thing and will probably be the approach we go with. > > 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.
At 01:16 PM 1/26/2004, you wrote:>What about SOAP (or would this be an RPC)? When a client connects, a SOAP >object is sent to the subscription/authorization server containing the >username, password and requested mount. The auth server can then process >this and return true or false. Then when the client logs off, another >object would be sent to note that event. The cool thing about this is that >you can write whatever authorization logic you'd like. Icecast just has to >send the objects (and get a response when someone is logging on) with no >knowledge of how the decision to authenticate or not is made. Or is there >better/easier protocol or method to use to get the same effect? > >I would guess this could also be done with URL calls as well but how would >Icecast accept the response? Is this ability built into the httpp library?this approach is pretty much exactly what I was thinking, although I don't think SOAP is necessarily the right approach, a simple URL call will suffice for this...the communication protocol would be fairly simple...Icecast passed user/pass/mount info via a URL call, and the URL call must respond with certain specified HTTP response headers indicating success or failure, and based on those responses icecast would accept or deny the client. the downside is that this would require plaintext users and password being sent over the wire, although since they are already coming IN using simple HTTP authentication, this is already being done, so not much different if you ask me.. we have alot of the infrastructure for URL calls already in icecast (due to the YP listing code which uses it) and so we can re-use alot of that. Mike has also implemented a simpler approach, which is also very useful and works the way apache .htpasswd files work. I think supporting both mechanisms is a good thing and will probably be the approach we go with. oddsock <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.