[icecast-dev] User authentication schemes

[Dave St John]

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 at oddsock.org>
To: <icecast-dev at 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 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
>
>
> --- >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.
>

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