<div dir="ltr">Hi Thomas,<div><br></div><div>Side question, mainly out of curiosity, are there examples/projects of using auth tokens from an IAM service like AWS or Google or a SSO site like Okta?</div><div><br></div><div>Jayesh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 15, 2019 at 1:31 AM Thomas B. Rücker <<a href="mailto:thomas@ruecker.fi">thomas@ruecker.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 9/14/19 7:39 PM, Mikel Sanz | 20 Comunicación wrote:<br>
> I would like to have a private signal, which can only be tuned by<br>
> whoever has the username and password, and know who is connected. But<br>
> I wish the URL could be delivered with the username and password, to<br>
> open it directly on a player or receiving device...<br>
<br>
<br>
Sounds like a (bearer) token in combination with URL-auth would be a<br>
more promising thing to look into.<br>
<br>
<a href="http://icecast.org/docs/icecast-2.4.1/auth.html#url" rel="noreferrer" target="_blank">http://icecast.org/docs/icecast-2.4.1/auth.html#url</a><br>
<br>
Basically you pass along a token to the listener software, e.g. like this:<br>
<br>
<a href="http://stream.example.org/music.opus?token=a0db5c27-f42c-4b81-85db-8a3642aac316" rel="noreferrer" target="_blank">http://stream.example.org/music.opus?token=a0db5c27-f42c-4b81-85db-8a3642aac316</a><br>
<br>
The token can be anything you choose, but you MUST control it. This<br>
means you generate the token e.g. during login to your website and then<br>
render URLs for that user with the token embedded into them.<br>
Then once they arrive at Icecast, it will make a request to your<br>
internal authentication endpoint to verify if the token is valid. If the<br>
answer is that the token is valid, the request is granted. It is then up<br>
to your own systems to enforce a number of concurrent requests or or<br>
limit concurrent requests in some sort of way like originating IP addresses.<br>
<br>
You have complete freedom to implement this the way you want. It is up<br>
to you to implement this though, of course.<br>
<br>
<br>
><br>
><br>
> El sáb., 14 sept. 2019 a las 21:33, Marvin Scholz (<<a href="mailto:epirat07@gmail.com" target="_blank">epirat07@gmail.com</a><br>
> <mailto:<a href="mailto:epirat07@gmail.com" target="_blank">epirat07@gmail.com</a>>>) escribió:<br>
><br>
><br>
><br>
>     On 14 Sep 2019, at 21:09, Mikel Sanz | 20 Comunicación wrote:<br>
><br>
>     > Hi. I'm trying to set up a mountpoint with authentication<br>
>     type="htpasswd".<br>
>     ><br>
>     > It's correctly set up, but I have problems to listen in some<br>
>     players. In<br>
>     > Winamp, I've tried this URL structure:<br>
>     > http://user:password@server:port/mountpoint.<br>
>     > But in VLC, with same structure, a window is opened requesting<br>
>     that data<br>
>     > every time.<br>
><br>
>     This is a bug in VLC. Anyway you should avoid to put the username and<br>
>     password in the URL as thats a potential security issue.<br>
><br>
>     ><br>
>     > In HTML5 players, the same problem.<br>
>     ><br>
>     > How can I play this audio stream with user and password in the URL?<br>
><br>
>     What exactly is your usecase?<br>
><br>
>     ><br>
><br>
<br>
Cheers,<br>
<br>
TBR<br>
<br>
<br>
_______________________________________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/icecast" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/icecast</a><br>
</blockquote></div>