HTTP API incorrectly returns HTTP 401 response when credentials are present but incorrect

[JHahnHRO]

Summary: RabbitMQ 3.8.14 (EDIT: I could also reproduce this on 3.8.3) returns an invalid HTTP 401 response when I try to access the management api with wrong credentials.

Steps to reproduce: Direct with curl

C:\Windows\system32>curl -v http://<HOST>:15672/api/overview -u wronguser:wrongpw
*   Trying <IP_OF_HOST>...
* TCP_NODELAY set
* Connected to <HOST> (<IP_OF_HOST>) port 15672 (#0)
* Server auth using Basic with user 'wronguser'
> GET /api/overview HTTP/1.1
> Host: <HOST>:15672
> Authorization: Basic d3Jvbmd1c2VyOndyb25ncHc=
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< content-length: 50
< content-security-policy: script-src 'self' 'unsafe-eval' 'unsafe-inline'; object-src 'self'
< content-type: application/json
< date: Thu, 08 Jul 2021 15:05:00 GMT
< server: Cowboy
< vary: origin
<
{"error":"not_authorised","reason":"Login failed"}

What goes wrong?

That seems like a reasonable response, but isn't. RFC-7235 demands that a HTTP 401 response MUST be accompanied by an WWW-Authenticate header. This header is present upon a GET request without credentials, but not when (wrong) credentials are provided.

What was expected instead?

Either the 401 response should contain the header even when a login attempt failed or the response should have status HTTP 403 instead.

[deadtrickster]

Hi, the fix just got merged, please retest :-)

[michaelklishin]

The easiest option would be to use a preview release build when it is out for 3.8.20. Alpha builds are also available but they are intentionally only kept for a week or two, and only up to a certain number of them.

[gerhard]

While going over the 3.8.20 release notes, I was wondering whether this should be in v3.9.x too?

[lhoguin]

This is in v3.9.x already. 70e0798

[gerhard]

Got it! I just confirmed that it went out in v3.9.0.