View previous topic :: View next topic |
Author |
Message |
iunderwood
Joined: 23 Aug 2008 Posts: 114 Location: Leicester, MA
|
Posted: Sat Oct 10, 2009 12:55 am Post subject: Authentication w/ Intro |
|
|
Yummy. Can't wait to put this together in UHQ-IceAuth for XOOPS.
One quick question ... does the response header need a content/type appended to the header before sending the intro file down? _________________ ++I; |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sat Oct 10, 2009 1:24 am Post subject: |
|
|
It is not required. At the point of a listener_add response, the intro content can be assumed to be in the same format as the stream. If there was a mismatch in content type then the only thing we could do is ignore the content.
karl. |
|
Back to top |
|
|
iunderwood
Joined: 23 Aug 2008 Posts: 114 Location: Leicester, MA
|
Posted: Sat Oct 10, 2009 7:28 pm Post subject: |
|
|
I have a small piece of this working, but not all of it, unfortunately.
In each of my authentication mountpoints, I have the following option set:
<option name="auth_header" value="icecast-auth-user: 1" />
However, when I send "icecast-auth-user: withintro", VLC reports it as a login failure and asks me for a un/pw.
I think it might be better to add a separate header to the response ... something like "icecast-auth-intro: 1" to specify that introduction data follows. That will allow the auth_header option to continue to work properly.
I have deduced this from the access log, which fails on "withintro"
Code: |
96.32.x.x - - [10/Oct/2009:15:19:38 -0400] "GET /pf-64k.ogg HTTP/1.1" 401 118 "-" "VLC media player - version 1.0.2 Goldeneye - (c) 1996-2009 the VideoLAN team" 1 |
Yet, with the option set as prior:
Code: |
96.32.x.x - - [10/Oct/2009:15:26:13 -0400] "GET /pf-64k.ogg HTTP/1.1" 200 2853712 "-" "VLC media player - version 1.0.2 Goldeneye - (c) 1996-2009 the VideoLAN team" 316 |
_________________ ++I; |
|
Back to top |
|
|
iunderwood
Joined: 23 Aug 2008 Posts: 114 Location: Leicester, MA
|
Posted: Sat Oct 10, 2009 7:38 pm Post subject: |
|
|
Nevermind, I posted prematurely.
I ended up needing to use "icecast-auth-user: 1 withintro"
Not to sound crass Karl, but that is f'ing sweet! _________________ ++I; |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sat Oct 10, 2009 9:08 pm Post subject: |
|
|
The default setting now is effectively
<option name="auth_header" value="icecast-auth-user" />
as that is what the header name should be, remember someone could use a different header name like
allow-user: withintro
The other possible setting we could do is something like
icecast-auth-user: intro=/somefile
but this is a bit more involved within icecast.
karl. |
|
Back to top |
|
|
iunderwood
Joined: 23 Aug 2008 Posts: 114 Location: Leicester, MA
|
Posted: Sun Oct 11, 2009 12:03 am Post subject: |
|
|
Ok ... now I understand the sematic a little better as far as handling the trigger and whatnot.
Since it's possible to upload a rather large intro, are there any limits that may need to be adjusted in buffering and whatnot if a large introduction gets pushed out? _________________ ++I; |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sun Oct 11, 2009 12:22 am Post subject: |
|
|
nothing really configurable for that. It will be burst quickly just like the more traditional configured intro. I may be able to apply a limiter based on the average bitrate of the stream.
karl. |
|
Back to top |
|
|
|