On Tue, May 28, 2019 at 2:50 AM Philipp Schafft < phschafft at de.loewenfelsen.net> wrote:> Good morning, > > On Mon, 2019-05-27 at 22:09 -0700, Thiago Sousa Santos wrote: > > Hello, > > > > I'd like to have my icecast client (libshout based) that would use the > HTTP > > header: > > > > "Authorization: bearer <token>" > > > > as its authentication method. I didn't find documentation on how to do > it, > > also couldn't find anything like that in libshout source code. Is this > > possible in the current code? > > No. > > > > Additionally, if not possible, is this feature something interesting to > > have at libshout or should I use something else? > > I actually thought about it several times the last year. However it has > not proven very useful to an Icecast based system because RFC 6750 which > defines it is missing a very important point: There is no way to inform > the client about the token. It is always transferred via a side channel > (from the HTTP perspective). > > This not-so-little details renders it mostly useless in my opinion. > > I wonder, why do you want it? No official Icecast can work with it > anyway? >I'm working on our own client that would require authentication to a service before users can stream from Icecast. 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?> > Also feel free to join us for a little chat about it on IRC: > https://icecast.org/contact/#contact-info > >Thanks for the help, I just joined and I'm thiagoss.> > With best regards, > > -- > Philipp Schafft (CEO/Geschäftsführer) > Telephon: +49.3535 490 17 92 > > Löwenfelsen UG (haftungsbeschränkt) Registration number: > Bickinger Straße 21 HRB 12308 CB > 04916 Herzberg (Elster) VATIN/USt-ID: > Germany DE305133015 > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >-- Thiago Sousa Santos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190528/25ab5e74/attachment.html>
how can i be able to have my own streaming server ????? On Tue, May 28, 2019 at 6:42 PM Thiago Sousa Santos <thiagossantos at gmail.com> wrote:> > > On Tue, May 28, 2019 at 2:50 AM Philipp Schafft < > phschafft at de.loewenfelsen.net> wrote: > >> Good morning, >> >> On Mon, 2019-05-27 at 22:09 -0700, Thiago Sousa Santos wrote: >> > Hello, >> > >> > I'd like to have my icecast client (libshout based) that would use the >> HTTP >> > header: >> > >> > "Authorization: bearer <token>" >> > >> > as its authentication method. I didn't find documentation on how to do >> it, >> > also couldn't find anything like that in libshout source code. Is this >> > possible in the current code? >> >> No. >> >> >> > Additionally, if not possible, is this feature something interesting to >> > have at libshout or should I use something else? >> >> I actually thought about it several times the last year. However it has >> not proven very useful to an Icecast based system because RFC 6750 which >> defines it is missing a very important point: There is no way to inform >> the client about the token. It is always transferred via a side channel >> (from the HTTP perspective). >> >> This not-so-little details renders it mostly useless in my opinion. >> >> I wonder, why do you want it? No official Icecast can work with it >> anyway? >> > > I'm working on our own client that would require authentication to a > service before users can stream from Icecast. > 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? > > >> >> Also feel free to join us for a little chat about it on IRC: >> https://icecast.org/contact/#contact-info >> >> > Thanks for the help, I just joined and I'm thiagoss. > > >> >> With best regards, >> >> -- >> Philipp Schafft (CEO/Geschäftsführer) >> Telephon: +49.3535 490 17 92 >> >> Löwenfelsen UG (haftungsbeschränkt) Registration number: >> Bickinger Straße 21 HRB 12308 CB >> 04916 Herzberg (Elster) VATIN/USt-ID: >> Germany DE305133015 >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast >> > > > -- > Thiago Sousa Santos > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190528/5f002468/attachment.html>
Hi Jay, http://icecast.org/docs/icecast-2.4.1/ would be a fantastic place to start. Cheers, Jordan On 5/28/19 12:13 PM, Jay George wrote:> how can i be able to have my own streaming server ????? > > On Tue, May 28, 2019 at 6:42 PM Thiago Sousa Santos > <thiagossantos at gmail.com <mailto:thiagossantos at gmail.com>> wrote: > > > > On Tue, May 28, 2019 at 2:50 AM Philipp Schafft > <phschafft at de.loewenfelsen.net > <mailto:phschafft at de.loewenfelsen.net>> wrote: > > Good morning, > > On Mon, 2019-05-27 at 22:09 -0700, Thiago Sousa Santos wrote: > > Hello, > > > > I'd like to have my icecast client (libshout based) that would > use the HTTP > > header: > > > > "Authorization: bearer <token>" > > > > as its authentication method. I didn't find documentation on > how to do it, > > also couldn't find anything like that in libshout source code. > Is this > > possible in the current code? > > No. > > > > Additionally, if not possible, is this feature something > interesting to > > have at libshout or should I use something else? > > I actually thought about it several times the last year. However > it has > not proven very useful to an Icecast based system because RFC > 6750 which > defines it is missing a very important point: There is no way to > inform > the client about the token. It is always transferred via a side > channel > (from the HTTP perspective). > > This not-so-little details renders it mostly useless in my opinion. > > I wonder, why do you want it? No official Icecast can work with it > anyway? > > > I'm working on our own client that would require authentication to a > service before users can stream from Icecast. > 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? > > > > Also feel free to join us for a little chat about it on IRC: > https://icecast.org/contact/#contact-info > > > Thanks for the help, I just joined and I'm thiagoss. > > > > With best regards, > > -- > Philipp Schafft (CEO/Geschäftsführer) > Telephon: +49.3535 490 17 92 > > Löwenfelsen UG (haftungsbeschränkt) Registration number: > Bickinger Straße 21 HRB 12308 CB > 04916 Herzberg (Elster) VATIN/USt-ID: > Germany DE305133015 > _______________________________________________ > Icecast mailing list > Icecast at xiph.org <mailto:Icecast at xiph.org> > http://lists.xiph.org/mailman/listinfo/icecast > > > > -- > Thiago Sousa Santos > _______________________________________________ > Icecast mailing list > Icecast at xiph.org <mailto:Icecast at xiph.org> > http://lists.xiph.org/mailman/listinfo/icecast > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >