I would like to have a private signal, which can only be tuned by whoever has the username and password, and know who is connected. But I wish the URL could be delivered with the username and password, to open it directly on a player or receiving device... Thanks. El sáb., 14 sept. 2019 a las 21:33, Marvin Scholz (<epirat07 at gmail.com>) escribió:> > > On 14 Sep 2019, at 21:09, Mikel Sanz | 20 Comunicación wrote: > > > Hi. I'm trying to set up a mountpoint with authentication > type="htpasswd". > > > > It's correctly set up, but I have problems to listen in some players. In > > Winamp, I've tried this URL structure: > > http://user:password at server:port/mountpoint. > > But in VLC, with same structure, a window is opened requesting that data > > every time. > > This is a bug in VLC. Anyway you should avoid to put the username and > password in the URL as thats a potential security issue. > > > > > In HTML5 players, the same problem. > > > > How can I play this audio stream with user and password in the URL? > > What exactly is your usecase? > > > > > Thanks! > > _______________________________________________ > > Icecast mailing list > > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190914/128ed534/attachment.html>
On 14 Sep 2019, at 21:39, Mikel Sanz | 20 Comunicación wrote:> I would like to have a private signal, which can only be tuned by whoever > has the username and password, and know who is connected. But I wish the > URL could be delivered with the username and password, to open it directly > on a player or receiving device... Thanks. >Then http://user:password at server:port/mountpoint is the way to go, which is supported by most players.> > El sáb., 14 sept. 2019 a las 21:33, Marvin Scholz (<epirat07 at gmail.com>) > escribió: > >> >> >> On 14 Sep 2019, at 21:09, Mikel Sanz | 20 Comunicación wrote: >> >>> Hi. I'm trying to set up a mountpoint with authentication >> type="htpasswd". >>> >>> It's correctly set up, but I have problems to listen in some players. In >>> Winamp, I've tried this URL structure: >>> http://user:password at server:port/mountpoint. >>> But in VLC, with same structure, a window is opened requesting that data >>> every time. >> >> This is a bug in VLC. Anyway you should avoid to put the username and >> password in the URL as thats a potential security issue. >> >>> >>> In HTML5 players, the same problem. >>> >>> How can I play this audio stream with user and password in the URL? >> >> What exactly is your usecase? >> >>> >>> Thanks! >>> _______________________________________________ >>> Icecast mailing list >>> 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 >> > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast
Yes, it is the first thing I have tried, but I have encountered this problem. If I enable option <option name="allow_duplicate_users" value="1"/>, it works fine. But if set to 0, to limit one connection per user, it does not work properly and forces you to manually enter the data again. It seems that there are players who make 2 requests, and being limited to 1, makes the message appear. These are the tests performed with authentication enabled and "allow_duplicate_users = 0" - If I try to enter the URL without the username and password inside, ask for authentication, and after entering the data, asks for it a second time and after enter the user and password again, plays the stream. - If I try to enter the URL with the username and password inside, ask for authentication via pop-up only once (tested with VLC and Chrome), and plays. These are the tests performed with authentication enabled and "allow_duplicate_users = 1" - If I try to enter the URL without the username and password inside, ask for authentication once and plays. - If I try to enter the URL with the username and password inside, it plays. That is, it seems that some players generate more than 1 request, and being limited the connection of each user to a connection, prevents the direct play and asks for user and password one more time... El sáb., 14 sept. 2019 a las 21:46, Marvin Scholz (<epirat07 at gmail.com>) escribió:> > > On 14 Sep 2019, at 21:39, Mikel Sanz | 20 Comunicación wrote: > > > I would like to have a private signal, which can only be tuned by whoever > > has the username and password, and know who is connected. But I wish the > > URL could be delivered with the username and password, to open it > directly > > on a player or receiving device... Thanks. > > > > Then http://user:password at server:port/mountpoint is the way to go, > which is supported by most players. > > > > > El sáb., 14 sept. 2019 a las 21:33, Marvin Scholz (<epirat07 at gmail.com>) > > escribió: > > > >> > >> > >> On 14 Sep 2019, at 21:09, Mikel Sanz | 20 Comunicación wrote: > >> > >>> Hi. I'm trying to set up a mountpoint with authentication > >> type="htpasswd". > >>> > >>> It's correctly set up, but I have problems to listen in some players. > In > >>> Winamp, I've tried this URL structure: > >>> http://user:password at server:port/mountpoint. > >>> But in VLC, with same structure, a window is opened requesting that > data > >>> every time. > >> > >> This is a bug in VLC. Anyway you should avoid to put the username and > >> password in the URL as thats a potential security issue. > >> > >>> > >>> In HTML5 players, the same problem. > >>> > >>> How can I play this audio stream with user and password in the URL? > >> > >> What exactly is your usecase? > >> > >>> > >>> Thanks! > >>> _______________________________________________ > >>> Icecast mailing list > >>> 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 > >> > > _______________________________________________ > > Icecast mailing list > > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190914/02134ad9/attachment.html>
Hi, On 9/14/19 7:39 PM, Mikel Sanz | 20 Comunicación wrote:> I would like to have a private signal, which can only be tuned by > whoever has the username and password, and know who is connected. But > I wish the URL could be delivered with the username and password, to > open it directly on a player or receiving device...Sounds like a (bearer) token in combination with URL-auth would be a more promising thing to look into. http://icecast.org/docs/icecast-2.4.1/auth.html#url Basically you pass along a token to the listener software, e.g. like this: http://stream.example.org/music.opus?token=a0db5c27-f42c-4b81-85db-8a3642aac316 The token can be anything you choose, but you MUST control it. This means you generate the token e.g. during login to your website and then render URLs for that user with the token embedded into them. Then once they arrive at Icecast, it will make a request to your internal authentication endpoint to verify if the token is valid. If the answer is that the token is valid, the request is granted. It is then up to your own systems to enforce a number of concurrent requests or or limit concurrent requests in some sort of way like originating IP addresses. You have complete freedom to implement this the way you want. It is up to you to implement this though, of course.> > > El sáb., 14 sept. 2019 a las 21:33, Marvin Scholz (<epirat07 at gmail.com > <mailto:epirat07 at gmail.com>>) escribió: > > > > On 14 Sep 2019, at 21:09, Mikel Sanz | 20 Comunicación wrote: > > > Hi. I'm trying to set up a mountpoint with authentication > type="htpasswd". > > > > It's correctly set up, but I have problems to listen in some > players. In > > Winamp, I've tried this URL structure: > > http://user:password at server:port/mountpoint. > > But in VLC, with same structure, a window is opened requesting > that data > > every time. > > This is a bug in VLC. Anyway you should avoid to put the username and > password in the URL as thats a potential security issue. > > > > > In HTML5 players, the same problem. > > > > How can I play this audio stream with user and password in the URL? > > What exactly is your usecase? > > > >Cheers, TBR
Hi Thomas, 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? Jayesh On Sun, Sep 15, 2019 at 1:31 AM Thomas B. Rücker <thomas at ruecker.fi> wrote:> Hi, > > On 9/14/19 7:39 PM, Mikel Sanz | 20 Comunicación wrote: > > I would like to have a private signal, which can only be tuned by > > whoever has the username and password, and know who is connected. But > > I wish the URL could be delivered with the username and password, to > > open it directly on a player or receiving device... > > > Sounds like a (bearer) token in combination with URL-auth would be a > more promising thing to look into. > > http://icecast.org/docs/icecast-2.4.1/auth.html#url > > Basically you pass along a token to the listener software, e.g. like this: > > > http://stream.example.org/music.opus?token=a0db5c27-f42c-4b81-85db-8a3642aac316 > > The token can be anything you choose, but you MUST control it. This > means you generate the token e.g. during login to your website and then > render URLs for that user with the token embedded into them. > Then once they arrive at Icecast, it will make a request to your > internal authentication endpoint to verify if the token is valid. If the > answer is that the token is valid, the request is granted. It is then up > to your own systems to enforce a number of concurrent requests or or > limit concurrent requests in some sort of way like originating IP > addresses. > > You have complete freedom to implement this the way you want. It is up > to you to implement this though, of course. > > > > > > > > El sáb., 14 sept. 2019 a las 21:33, Marvin Scholz (<epirat07 at gmail.com > > <mailto:epirat07 at gmail.com>>) escribió: > > > > > > > > On 14 Sep 2019, at 21:09, Mikel Sanz | 20 Comunicación wrote: > > > > > Hi. I'm trying to set up a mountpoint with authentication > > type="htpasswd". > > > > > > It's correctly set up, but I have problems to listen in some > > players. In > > > Winamp, I've tried this URL structure: > > > http://user:password at server:port/mountpoint. > > > But in VLC, with same structure, a window is opened requesting > > that data > > > every time. > > > > This is a bug in VLC. Anyway you should avoid to put the username and > > password in the URL as thats a potential security issue. > > > > > > > > In HTML5 players, the same problem. > > > > > > How can I play this audio stream with user and password in the URL? > > > > What exactly is your usecase? > > > > > > > > > Cheers, > > TBR > > > _______________________________________________ > 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/20190915/3e9d7c49/attachment.html>