<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 28, 2019 at 2:50 AM Philipp Schafft <<a href="mailto:phschafft@de.loewenfelsen.net">phschafft@de.loewenfelsen.net</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">Good morning,<br>
<br>
On Mon, 2019-05-27 at 22:09 -0700, Thiago Sousa Santos wrote:<br>
> Hello,<br>
> <br>
> I'd like to have my icecast client (libshout based) that would use the HTTP<br>
> header:<br>
> <br>
> "Authorization: bearer <token>"<br>
> <br>
> as its authentication method. I didn't find documentation on how to do it,<br>
> also couldn't find anything like that in libshout source code. Is this<br>
> possible in the current code?<br>
<br>
No.<br>
<br>
<br>
> Additionally, if not possible, is this feature something interesting to<br>
> have at libshout or should I use something else?<br>
<br>
I actually thought about it several times the last year. However it has<br>
not proven very useful to an Icecast based system because RFC 6750 which<br>
defines it is missing a very important point: There is no way to inform<br>
the client about the token. It is always transferred via a side channel<br>
(from the HTTP perspective).<br>
<br>
This not-so-little details renders it mostly useless in my opinion.<br>
<br>
I wonder, why do you want it? No official Icecast can work with it<br>
anyway?<br></blockquote><div><br></div><div>I'm working on our own client that would require authentication to a service before users can stream from Icecast.</div><div>The idea is that they authenticate and get a token from this service and, when connecting to Icecast, they sent this same token. Icecast will be configured to forward the HTTP header to the same service so that it can identify and authorize the user before it can receive the stream. This is still at the planning phase and, so far, the client would have to be specific to this service because of this authentication requirement. Is there a better alternative to this authentication that would work out of the box, assuming there is a separate service that needs also to auth the same users?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also feel free to join us for a little chat about it on IRC:<br>
<a href="https://icecast.org/contact/#contact-info" rel="noreferrer" target="_blank">https://icecast.org/contact/#contact-info</a><br>
<br></blockquote><div><br></div><div>Thanks for the help, I just joined and I'm thiagoss.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
With best regards,<br>
<br>
-- <br>
Philipp Schafft (CEO/Geschäftsführer) <br>
Telephon: +49.3535 490 17 92<br>
<br>
Löwenfelsen UG (haftungsbeschränkt)     Registration number:<br>
Bickinger Straße 21                     HRB 12308 CB<br>
04916 Herzberg (Elster)                 VATIN/USt-ID:<br>
Germany                                 DE305133015<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><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Thiago Sousa Santos</div></div>