Michael Smith
2004-Aug-06 14:57 UTC
[icecast-dev] icecast2 ogg vorbis client request headers
On Saturday 03 April 2004 02:22, oddsock wrote:> I think the plan is to add a URL based authentication, which would allow > you to make a call to an arbitrary script (PHP, CGI, etc) which could do > whatever you'd like (look up users in a mySQL db, look up in a local file, > whatever)...this, I think, provides the most flexibility, and also pushes > off alot of the authentication logic off of icecast where it doesn't really > belong...That was your plan. My plan is to provide what currently exists (htpasswd-like) and a 'script' authenticator which just calls an external program, as Geoff described. Both are, of course, possible. Your "URL call" (this is a very strange way to describe it, by the way - I assume you mean "HTTP connection") approach is much more complex to implement well, though, without obviously being more powerful. Mike --- >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 07:41 PM 4/4/2004, you wrote:>That was your plan. > >My plan is to provide what currently exists (htpasswd-like) and a 'script' >authenticator which just calls an external program, as Geoff described. > >Both are, of course, possible. Your "URL call" (this is a very strange way to >describe it, by the way - I assume you mean "HTTP connection") approach is >much more complex to implement well, though, without obviously being more >powerful.invoking a URL is what I mean, I call it "URL Call" you call it HTTP connection, it's the same thing...as you well know. and considering the way many broadcasters have implemented authentication (and I know more than a few that have, and they ALL have done it via a "URL call" type method), I would say this method is more conventional than the "invoke a script" type method. And if you ask me, having icecast fork and exec a script to do listener authentication is not going to scale too well (I hope you don't plan to fork/exec for every listener connection). AND we already have the infrastructure for making URL calls (the YP code has to do it). But obviously I would not be against implementing a script-based authenticator, although this is pretty useless for most Win32 users (yes there are a bunch of those out there) as most Win32 users don't generally script things... 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.
Michael Smith
2004-Aug-06 14:57 UTC
[icecast-dev] icecast2 ogg vorbis client request headers
On Monday 05 April 2004 13:04, oddsock wrote:> At 07:41 PM 4/4/2004, you wrote: > >That was your plan. > > > >My plan is to provide what currently exists (htpasswd-like) and a 'script' > >authenticator which just calls an external program, as Geoff described. > > > >Both are, of course, possible. Your "URL call" (this is a very strange way > > to describe it, by the way - I assume you mean "HTTP connection") > > approach is much more complex to implement well, though, without > > obviously being more powerful. > > invoking a URL is what I mean, I call it "URL Call" you call it HTTP > connection, it's the same thing...as you well know.Yes. Your meaning was clear, but it's very unconventional (and inaccurate, technically - which matters later on when we document it, though not so much now) teminology.> > and considering the way many broadcasters have implemented authentication > (and I know more than a few that have, and they ALL have done it via a "URL > call" type method), I would say this method is more conventional than the > "invoke a script" type method. And if you ask me, having icecast fork and > exec a script to do listener authentication is not going to scale too well > (I hope you don't plan to fork/exec for every listener connection). AND we > already have the infrastructure for making URL calls (the YP code has to do > it).I'm not entirely sure of the performance implications on win32 - I'm told it'll be substantially slower than on unix systems, but whether this matters or not I'm not sure. Certainly, on a typical unix system, this approach (fork and exec some program for each and every listener connection) will drastically out-perform an HTTP request for simple cases (i.e. if, in both cases, the actual authentication logic is simple/quick). The simple/naive implementation will definately scale acceptably well on unix systems. For this sort of thing, most implementations probably won't be simple/quick, so the difference will likely end up in the noise (if the HTTP request is on a local network, at least). Persistent HTTP connections (for which we don't have the infrastructure currently) help this a lot - but similarly, given more effort, the script approach could use a persistent "authentication daemon". You can get sufficient performance either way if you really need it. This approach also lets you get the http-request approach 'for free' - you just provide a script that does an HTTP request to some URL and returns the appropriate value. <p><p><p>>> But obviously I would not be against implementing a script-based > authenticator, although this is pretty useless for most Win32 users (yes > there are a bunch of those out there) as most Win32 users don't generally > script things...The only reason this would be 'useless for most win32 users' is if the overhead of running an executable for every request is too high on that OS. I don't know whether it is. Remember, even if we call it a "script authentication module", there's nothing to force it to be in any sort of actual "scripting language". Mike --- >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.