Hello, Is HTTP basic authentication the only way for icecast to perform authentication ? With a link like http://username:password at example.com:8000/mystream (HTTP basic authentication) it has a number of problems regarding browsers. Chrome for security reasons does not follow the link and shows a popup asking to enter the credentials but this destroys user experience for a site with a webplayer. It works fine afterwards. Internet Explorer does the same. It would be ideal if icecast would get the credentials from the GET parameters, something similar to http://example.com:8000/mystream?user=username&pass=password this would eliminate the browser problems with the basic auth. I am willing to implement something like this as it seems relatively simple. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/icecast-dev/attachments/20150113/3d4436c8/attachment.htm
Hi, On 01/13/2015 03:47 PM, dtouch3d completely wrote:> Is HTTP basic authentication the only way for icecast to perform > authentication ? With a link like > > http://username:password at example.com:8000/mystream >No, you are misunderstanding HTTP auth. Parameters in the URL is not the only way and has been largely out of fashion since the end of the last millennium. Most software nowadays expects the credentials outside the URL. Even XMLHTTPRequest has own parameters for that if you look at web browsers.> (HTTP basic authentication) it has a number of problems regarding > browsers. Chrome for security reasons does not follow the link and > shows a popup asking to enter the credentials but this destroys user > experience for a site with a webplayer. It works fine afterwards. > Internet Explorer does the same.That particular use case won't work well with standard HTTP authentication, by design. Saying that it "destroys user experience" is a bit harsh and will completely depend on circumstances. If you authenticate the user otherwise, it is certainly redundant, but see below.> It would be ideal if icecast would get the credentials from the GET > parameters, something similar to > > http://example.com:8000/mystream?user=username&pass=password >You can do that if you use the URL auth backend: http://icecast.org/docs/icecast-2.4.1/auth.html#url> this would eliminate the browser problems with the basic auth.Just use URL auth, pass a session ID, or other token, you can also pass a cookie, etc. As this is an advanced feature we don't offer it for the plain htpasswd auth.> I am willing to implement something like this as it seems relatively > simple.In addition I should mention, that we have completely rewritten (most work was by ph3) the authentication backend after 2.4.1. This is going to be in the 2.5.0 release planned for later this year. This feature is still limited to URL auth though, IIRC. If you'd like to map parameters to user/password also for type 'htpasswd' and 'static', we could be interested in a patch. I'd recommend to discuss this with PH3 on IRC though, to avoid problems with how we structure the config XML. Cheers Thomas PS: In addition you're using HTML email, please don't, thank you.
Would be better to try directly https protocol, to be more secure. https://username:password at example.com:8000/mystream renan On 13/01/2015 16:47, dtouch3d completely wrote:> Hello, > > Is HTTP basic authentication the only way for icecast to perform > authentication ? With a link like > > http://username:password at example.com:8000/mystream > > (HTTP basic authentication) it has a number of problems regarding > browsers. Chrome for security reasons does not follow the link and shows > a popup asking to enter the credentials but this destroys user > experience for a site with a webplayer. It works fine afterwards. > Internet Explorer does the same. > > It would be ideal if icecast would get the credentials from the GET > parameters, something similar to > > http://example.com:8000/mystream?user=username&pass=password > > this would eliminate the browser problems with the basic auth. > > I am willing to implement something like this as it seems relatively simple. > > > _______________________________________________ > Icecast-dev mailing list > Icecast-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-dev >-- renan jegouzo software developer aestesis.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 601 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20150113/22c9b2ec/attachment.pgp
>> It would be ideal if icecast would get the credentials from the GET >> parameters, something similar to >> >> http://example.com:8000/mystream?user=username&pass=password >> > > You can do that if you use the URL auth backend: > http://icecast.org/docs/icecast-2.4.1/auth.html#url >Thanks! Appending parameters to the url is possible because it passed to the external url in the mount property, and icecast doesn't mind serving the right mount point. I don't remember seeing this in the docs though, I think it would be good addition. Also, sorry about the HTML, gmail changed the format to "rich text" for some reason. On Tue, Jan 13, 2015 at 6:25 PM, renan jegouzo <renan at aestesis.org> wrote:> Would be better to try directly https protocol, to be more secure.You are right, that would be more secure. The credentials are now sent unencrypted. But this means icecast must support this functionality and I have not seen anything in the docs. Is this supported ?
reflum, On Tue, 2015-01-13 at 16:16 +0000, "Thomas B. R?cker" wrote:> On 01/13/2015 03:47 PM, dtouch3d completely wrote: > > Is HTTP basic authentication the only way for icecast to perform > > authentication ?No. See below.> With a link like > > > > http://username:password at example.com:8000/mystream > > > > No, you are misunderstanding HTTP auth. Parameters in the URL is not the > only way and has been largely out of fashion since the end of the last > millennium. > Most software nowadays expects the credentials outside the URL. Even > XMLHTTPRequest has own parameters for that if you look at web browsers.*supports*> > (HTTP basic authentication) it has a number of problems regarding > > browsers. Chrome for security reasons does not follow the link and > > shows a popup asking to enter the credentials but this destroys user > > experience for a site with a webplayer. It works fine afterwards. > > Internet Explorer does the same. > > That particular use case won't work well with standard HTTP > authentication, by design. > Saying that it "destroys user experience" is a bit harsh and will > completely depend on circumstances. If you authenticate the user > otherwise, it is certainly redundant, but see below.There is still a world outside a browser yet inside the house ;).> > It would be ideal if icecast would get the credentials from the GET > > parameters, something similar to > > > > http://example.com:8000/mystream?user=username&pass=password > > > > You can do that if you use the URL auth backend: > http://icecast.org/docs/icecast-2.4.1/auth.html#url > > > > this would eliminate the browser problems with the basic auth. > > Just use URL auth, pass a session ID, or other token, you can also pass > a cookie, etc. > As this is an advanced feature we don't offer it for the plain htpasswd > auth.With the new role based system there are a lot possibilities. Basically the auth backend has access to the client object and can use like every kind of check. I was even thinking about TLS client cert auth. If you authenticated the client earlier already there are a lot possible ways to go... Yet if this is only about transmitting a username and password I would NOT go for breaking the standard. It is this way for a good reason. E.g. think of get parameters: they will end up on display (general term) and e.g. also in bookmarks and that way on disk. Also there is no way for software to detect the meaning of them so they can not handle stuff nicely. Think of typo in password. They simply can not prompt you for a correct one as they do not understand how to provide it.> > I am willing to implement something like this as it seems relatively > > simple. > > In addition I should mention, that we have completely rewritten (most > work was by ph3) the authentication backend after 2.4.1. This is going > to be in the 2.5.0 release planned for later this year. This feature is > still limited to URL auth though, IIRC. > > If you'd like to map parameters to user/password also for type > 'htpasswd' and 'static', we could be interested in a patch. I'd > recommend to discuss this with PH3 on IRC though, to avoid problems with > how we structure the config XML.I support this. If you want to help I'm the last one to object. Just join on IRC and talk to us. Have a nice day! -- Philipp. (Rah of PH2) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20150114/8acc4e64/attachment.pgp