search for: stream_auth

...of a bug in the Icecast code handling source client URL-authentication and are releasing a security fix. The bug was discovered by Juliane Holzt, who we'd like to thank for bringing this to our attention and providing us with further details. Affected Icecast versions: 2.3.3(first release with stream_auth) 2.4.0 2.4.1 Fix released in: 2.4.2 We do not release fixes for: 2.3.3: EOL 2.4.0: as 2.4.1 was a bugfix release for 2.4.0. The bug can only be triggered if "stream_auth" is being used, for example: <mount> <mount-name>/test.ogg</mount-name> <authentication typ...

...of a bug in the Icecast code handling source client URL-authentication and are releasing a security fix. The bug was discovered by Juliane Holzt, who we'd like to thank for bringing this to our attention and providing us with further details. Affected Icecast versions: 2.3.3(first release with stream_auth) 2.4.0 2.4.1 Fix released in: 2.4.2 We do not release fixes for: 2.3.3: EOL 2.4.0: as 2.4.1 was a bugfix release for 2.4.0. The bug can only be triggered if "stream_auth" is being used, for example: <mount> <mount-name>/test.ogg</mount-name> <authentication typ...

...ler wrote: > Hi, > > we are using Icecast with url authentication for some days now. This > generally works quite well. But our web service that provides the > authentication check sometimes gets requests with the following > parameters: > > { > "action":"stream_auth", > "mount":"/stream", > "ip":"xxxxx", > "server":"xxxx.yyyy.de", > "port":"12345", > "user":"", > "pass":"", > "admin":"1" > } &g...

On Wed, Jun 17, 2020 at 07:55:05AM +0000, Philipp Schafft wrote: > Why does Icecast forward both requests? Very simple: Not all auth setups > require username:password. E.g. some are only for logging and > accounting. Some auth using the IP address, which is already known in > the first request. Indeed. One of my streams has requested geoblocking, which uses exactly the mechanism you

Hi, we are using Icecast with url authentication for some days now. This generally works quite well. But our web service that provides the authentication check sometimes gets requests with the following parameters: { "action":"stream_auth", "mount":"/stream", "ip":"xxxxx", "server":"xxxx.yyyy.de", "port":"12345", "user":"", "pass":"", "admin":"1" } The passed username and password is empty...

...gt;> we are using Icecast with url authentication for some days now. This >> generally works quite well. But our web service that provides the >> authentication check sometimes gets requests with the following >> parameters: >> >> { >> "action":"stream_auth", >> "mount":"/stream", >> "ip":"xxxxx", >> "server":"xxxx.yyyy.de", >> "port":"12345", >> "user":"", >> "pass":"", >> "admin&q...

...entication via url, e.g.: > > <mount type="normal"> > ... > <password>something</password> > ... > </mount> > > <mount type="normal"> > ... > <authentication type="url"> > <option name="stream_auth" value="http://my.api/streamAuth"/> > <option name="auth_header" value="x-is-authenticated: 200 OK" /> > </authentication> > ... > </mount> > > this all works fine and stable. BUT when i add > > <mount type=&quot...

Is it possible to make Icecast run, for serving no more than 16 listeners, on Raspberry Pi? I simply want to dip my toe into the Linux universe, and this would be a fine excuse for me to try RP if it's doable. Thanks. Jeremiah Rogers Cell: 704-996-5334 Email: jeremiahzrogers at gmail.com Social Networking: /jzrogers

Hi, I am trying to bring up an Icecast service for users of a free & paid subscription system. Paid users can source a stream. Free signups can listen (auth) to the paid user's streams. My user data is in LDAP mainly, but I have a URI that returns "icecast-auth-user: 1" when passed the user= and pass= variables on the HTTP GET. AFAICT - the source password has to be

...using icecast-2.3.1 for some time now and it is really working well for me, solid as a rock (no crashes) and running 100's of streams and 1000's of listeners, but in order to support authentication and have easier configuration I want to start using the url authentication (esp. the stream_auth) and mount-name wildcards that are supported by icecast-2.3.2-kh17. I am unsure about the stability of icecast-2.3.2-kh17 when using url authentication for both stream and listener authentication. What are the major differences between icecast-2.3.2 and the kh17 branch and can you say anyt...

...="http://some.server.org/stream_control.php"/> <option name="listener_add" value="http://some.server.org/stream_control.php"/> <option name="listener_remove" value="http://some.server.org/stream_control.php"/> <option name="stream_auth" value="http://some.server.org/stream_control.php"/> <option name="user" value='source'/> <option name="pass" value='pass'/> <option name="auth_header" value="icecast-auth-user: 1"/> </authentication>...

...ast, like how the first listener that connects to an on-demand mount will always just an error. RSAS fixes all of these - on-demand mounts are reliable and work for the first listener. And to top it off, relaying on-demand with RSAS adds very little latency, which is very different from Icecast. - stream_auth supports HTTPS with RSAS, which is missing in Icecast 2.4. This was a big problem for me because it meant the web services that I wanted to use for stream_auth needed to send mount passwords over HTTP (insecure!). - CORS out-of-the-box - Streams are meant to be embedded and played everywhere, so t...

...l handle it, it's not something I've looked into, but if it does then HUP should work, and for 2.3.1, the new auth should apply for new listeners. There is another possibility which might be easier. In the -kh branch, where I have an updated auth engine, you can specify an option "stream_auth" with a uri that works in a similar way to the others. It's triggered when a source client tries to auth or when say metadata is updated on that stream. I haven't had much feedback on this but it seems to be working well enough. karl.

hello, now that i have dynamic source auth working fine, i wonder if it's possible to also create a souce dynamically, i.e. without defining a specific mount in icecast.xml? I've seen some hints, but havn't found it in the docs. tips appreciated, thanks, uno

...="http://some.server.org/stream_control.php"/> <option name="listener_add" value="http://some.server.org/stream_control.php"/> <option name="listener_remove" value="http://some.server.org/stream_control.php"/> <option name="stream_auth" value="http://some.server.org/stream_control.php"/> <option name="user" value='source'/> <option name="pass" value='pass'/> <option name="auth_header" value="icecast-auth-user: 1"/> </authentication>...

...tp://some.server.org/stream_control.php"/ <http://some.server.org/stream_control.php%22/>> > <option name="listener_remove" value="http://some.server.org/stream_control.php"/ <http://some.server.org/stream_control.php%22/>> > <option name="stream_auth" value="http://some.server.org/stream_control.php"/ <http://some.server.org/stream_control.php%22/>> > <option name="user" value='source'/> > <option name="pass" value='pass'/> > <option name="auth_header"...

...hat's the "quick and dirty" option. > I'm not aware of any way to do global source auth that would allow for > separate passwords for dynamic mount creation, but I'm also not really > aware of a use case for this either. This was already in 2.3.3, you can just use stream_auth http://icecast.org/docs/icecast-2.4.0/icecast2_auth.html (scroll to the bottom) You can combine this with: default mount Sorry, no official docs. Seems to have slipped through. But the Original ticket has enough info: https://trac.xiph.org/ticket/1914#comment:1 Start with <mount type="defa...

...script file descriptors, if the FD numbers go above 1024. This will be further addressed in the next Icecast release. * Don?t use comments inside <http-headers> as it will prevent processing of further <header> tags. * Web interface shows Login when using just stream_auth. Change log: http://svn.xiph.org/icecast/tags/icecast-2.4.1/ChangeLog Source tar ball: http://downloads.xiph.org/releases/icecast/icecast-2.4.1.tar.gz Windows build: http://downloads.xiph.org/releases/icecast/icecast_win32_2.4.1.zip Soon I'll also update the OBS repositories from 2.4.0 to...

...script file descriptors, if the FD numbers go above 1024. This will be further addressed in the next Icecast release. * Don?t use comments inside <http-headers> as it will prevent processing of further <header> tags. * Web interface shows Login when using just stream_auth. Change log: http://svn.xiph.org/icecast/tags/icecast-2.4.1/ChangeLog Source tar ball: http://downloads.xiph.org/releases/icecast/icecast-2.4.1.tar.gz Windows build: http://downloads.xiph.org/releases/icecast/icecast_win32_2.4.1.zip Soon I'll also update the OBS repositories from 2.4.0 to...

...gt;application/mp3</type> <subtype>mp3</subtype> <hidden>1</hidden> <burst-size>65536</burst-size> <mp3-metadata-interval>4096</mp3-metadata-interval> <authentication type="htpasswd"> <auth name="stream_auth" value="#" /> <option name="allow_duplicate_users" value="1"/> <!-- See authentication documentation --> </authentication> <http-headers> <header name="Access-Control-Allow-Origin" value="*" /&...