Icecast Streaming Media Server

[stereotype]

Karl, is it possible to add an <allow-agents> option in kh?
I want to restrict playback to a specific hardware's user agent string...
Or is there another way to do this?

Thanks

[karlH]

The only way to allow it at the moment is to use the url auth mechanism to [dis]allow the incoming user. The php attached to listener_add is sent the useragent in the POST.

karl.

[stereotype]

I see.
I use url auth but I still need user agent whitelisting due to passwords being stored as clear text in the hardware...
I guess I'll try blacklisting all the letters in the alphabet

[karlH]

who says you need a password, I thought the only requirement was checking on the useragent.

karl.

[stereotype]

I don't understand... url auth means using usernames and passwords no?
Are you saying I can use the aurl auth mechanism to block ua strings?

I actually need both passwords and ua string white listing

I talked about passwords being stored as clear text, meaning, users find the username and password from the equipment and then start playing the stream via other means... and there's nothing I can do about the hardware storing urls this way... I know users can still spoof the ua, but I only want to dis-encourage the practice, and not prevent it 100%...

[karlH]

no, url auth does not mean using usernames and passwords, you can use anything for auth,usernames, ip and query args are just examples. There is nothing to stop you from using useragent as the filtering mechanism.

query args can be made to be temporary eg

http://myserver:8000/stream?session=12345678901234567890

If you have a web portal dynamically generate the session id and place it in a playlist then you can expire that session after a few minutes. As long as when the player connects it's still valid then fine.

karl.

[stereotype]

interesting......
i don't know much about HTTP and POST

i'm looking at
http://www.icecast.org/docs/icecast-2.3.2/icecast2_listenerauth.html
but i'm still somewhat confused...

i don't get who passes what info to whom...
my server runs icecast only, so i guess i need to setup php?

and what is this php attached to listener_add you mention?

sorry for the many questions... i just don't understand how it all fits...

[karlH]

np, libcurl is just the library used to communicate with the backend you don't need to know how it's used just that icecast is built with it enabled.

When a player connects to icecast requesting a stream eg /stream then it checks to see if the listener_add option is specified and if so icecast calls the provided url passing the listeners details via POST. That url is invariably a php script that does whatever it needs to to determine whether the listener is ok to proceed (in your case, checks the useragent string). A returned header tells icecast to allow for disallow the incoming listener.

In the example I gave before, a web portal would generate a temporary key, build a playlist and return to the browser, that would then start the player and the player would pass those details onto icecast, icecast would then verify those details with the portal backend and then allow the listener to get content.

karl.

[stereotype]

Thanks karl

In a nutshell, this option:
<option name="listener_add" value="http://myauthserver.com/listener_joined.php"/>
calls the script, php does its thing, and returns a header.
The expected header is specified by:
<option name="auth_header" value="icecast-auth-user: 1"/>
Then bingo?

And I guess I can use icecast_auth.php from the tarball as a starting point?

[karlH]

That auth_header is the default, you can use your own customised header of course, but yes you have the mechanism there. The php script could be as simple as

header ("icecast-auth-user: 1");


karl.

[stereotype]

Can one run both HTPASSWD and URL auth methods on the same mount?
Only ask cause I already have HTPASSWD running well...
I could then use the URL method only for ua string screening...

[karlH]

no

karl

[stereotype]

I created a <deny-agents> file with 300 lines that blocks most of what I need...
Just can't seem to block empty user agent strings... They get through...
What would be the line entry for that?

[karlH]

I'm guessing you are using the kh tree for this, you can allow empty lines in I suppose ,which should then match the empty agent string. edit connection.c:recheck_cached_file around line 434 (depends on the version you have there), make it read

...
if (line[0] == '#')
continue;
count++;
cache->add_new_entry (new_ips, line, 0);
...

wildcards etc are allowed in the lines. I suspect the # check is not needed either really.

karl.