[Icecast-dev] HTTP Basic Auth alternative

[Philipp Schafft]

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@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