[Icecast] Empty username and password for stream_auth
Philipp Schafft
phschafft at de.loewenfelsen.net
Sat Jun 20 17:54:52 UTC 2020
Good evening,
On Wed, 2020-06-17 at 08:37 +0000, Christian Stoller wrote:
> Hi Philipp,
>
> Thanks for your reply. It really helped.
I'm happy to hear that. :)
> Did I understand you correctly that we should respond to those
> requests sent by Icecast without username and password with HTTP
> status code 200 and the header "Icecast-Auth-Message: No username
> provided"?
Yes. However I would more go for a 204 ("No data") as you will likely
not send any body.
Also, as always, test any changes before going live with them.
With best regards,
> > On Tue, 2020-06-16 at 13:25 +0000, Christian Stoller wrote:
> >> Hi,
> >>
> >> we are using Icecast with url authentication for some days now. This
> >> generally works quite well. But our web service that provides the
> >> authentication check sometimes gets requests with the following
> >> parameters:
> >>
> >> {
> >> "action":"stream_auth",
> >> "mount":"/stream",
> >> "ip":"xxxxx",
> >> "server":"xxxx.yyyy.de",
> >> "port":"12345",
> >> "user":"",
> >> "pass":"",
> >> "admin":"1"
> >> }
> >>
> >> The passed username and password is empty. Why does this happen and
> >> what should our authentication provider response to such a request?
> >
> > This is perfectly correct and totally expected:
> > HTTP does the auth in two steps: First a request is sent with no
> > credentials. In this step the request will pass (no credentials needed)
> > or the server will reply parameters on how to provide them. This is
> > important as otherwise the client would send credentials blindly,
> > allowing a wide range of attacks (both passive and active).
> >
> > If asked by the server, the client will then retry again with
> > credentials. Which will then let Icecast ask the backend again.
> >
> >
> > Why does Icecast forward both requests? Very simple: Not all auth setups
> > require username:password. E.g. some are only for logging and
> > accounting. Some auth using the IP address, which is already known in
> > the first request.
> >
> > (That said, Iecast 2.5.x (current development versions) can be
> > configured to reject those request without asking the backend.)
> >
> >
> >> Currently we response with HTTP status code 403 and the header
> >> "Icecast-Auth-Message: No username provided".
> >
> > If you require username:password for auth, then reject those requests to
> > let Icecast tell the client.
> >
> > Generally you should reply with a positive status code to Icecasts
> > requests. The status code you send is about the request from Icecast to
> > your backend server, not for the request from the client to Icecast.
> >
> >
> >> Icecast logs the following at the time of the request:
> >> > [2020-06-11 10:08:57] INFO auth/auth_stream_authenticate request
> >> source auth for "/stream"
> >> > [2020-06-11 10:08:57] INFO auth/queue_auth_client auth on /stream
> >> has 1 pending
> >> > [2020-06-11 10:08:57] WARN auth/stream_auth_callback Failed auth for
> >> source "/stream"
> >>
> >> I hope you can help me.
> >
> > Hope that helped. :)
> >
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200620/208e0b98/attachment.sig>
More information about the Icecast
mailing list