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>
On 14 Sep 2019, at 21:54, Mikel Sanz | 20 Comunicación wrote:> 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... >Yes. Some players generated multiple requests which causes issues with allow_duplicate_users set to false. There isn't much that could be done about this on Icecasts side.> > 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 >> > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast
Yes, I know, but, from what I see, the "allow_duplicate_users = 0" option is not really usable, because of these problems that it generates in many players. Therefore, I think it would be interesting for Icecast to allow the option to limit to 2 (or those defined in the configuration), so that it can be used and limited, at least. I think that new option is very necessary. El sáb., 14 sept. 2019 a las 22:09, Marvin Scholz (<epirat07 at gmail.com>) escribió:> > > On 14 Sep 2019, at 21:54, Mikel Sanz | 20 Comunicación wrote: > > > 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... > > > > Yes. Some players generated multiple requests which causes issues with > allow_duplicate_users set to false. There isn't much that could be done > about this on Icecasts side. > > > > > 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 > >> > > _______________________________________________ > > 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/5bb4f753/attachment.html>