Icecast dev - Oct 2004 - MySQL auth

On Sun, 2004-10-24 at 15:33, Mike Whitaker wrote:
> On 24 Oct 2004, at 13:25, Mike Whitaker wrote:
> 
> > Ooo. :)
> >
> > Having just had a look at auth_curl.c in kh, that would probably do 
> > what we want even better.
nice, these things aren't fully settled yet, for instance are enough
parameters passed etc.
> > Is it possible (or would it *be* possible) to make <mount>
sections
> > take wildcards for <mount-path>? From our viewpoint it'd be
much
> > easier to process whether the user is authorized to handle a  
> > *specific* stream in the auth URL, rather than by tweaking icecast.xml
> > every time we add a new stream.
wildcard type specifications are not handled, but adding/removing
<mount> sections is easy and only requires HUP to become ready for
incoming source connections (the kh branch applies most mount settings
on active streams as well).
> A oneline fix for you that drove me briefly mad till I realised that 
> CGI->header capitaliases the first character of custom headers:
> 
> src/auth_url.c: line 345 should read:
>      if (strncasecmp (ptr, "icecast-auth-user: 1", 20) == 0)
> 
> Other than that, I can report that my quick hack to test auth_url works 
> a treat :)
ok, although I don't think all platforms have that call although it can
be worked-around.

karl.

> wildcard type specifications are not handled, but adding/removing
> <mount> sections is easy and only requires HUP to become ready for
> incoming source connections (the kh branch applies most mount settings
> on active streams as well).
Useful. Does HUP interrupt live streams? I assume not.

Another question: will <authentication type="url"> work across a
master-slave relay?

On Mon, 2004-10-25 at 15:55, Mike Whitaker wrote:
> > wildcard type specifications are not handled, but adding/removing
> > <mount> sections is easy and only requires HUP to become ready
for
> > incoming source connections (the kh branch applies most mount settings
> > on active streams as well).
> 
> Useful. Does HUP interrupt live streams? I assume not.
No, any active streams are left as is, unless it's a relay that has just
been removed from the xml
> Another question: will <authentication type="url"> work
across a
> master-slave relay?
unfortunately the <mount> details don't transfer at the moment. In
some
cases it would seem reasonable as in the case of client auth, but for
say max listener count that would tend to be slave specific. It just
hasn't been decided on yet.

Nothing is stopping the <mount> definitions being specified in the slave
of course.

karl.