404 HTTP error instead of 401 for wrong password

1

I have a weird issue

I am getting a 404 from CHT outbound and 200 from curl for the “same” request

curl -X POST -d @test-data.json -u uuu:xxxx -H "Content-Type: application/json" https://lightning.dk.swisstph-mis.ch/i/511986ee-b2ed-4701-86ac-739a1016bab1

the weirdest is the lightning log that show the same path with 2 different errors

lightning-latest-web-1  | 13:05:02.470 request_id=GEE-AIwvQHJQgxAAAkKB [info] POST /i/511986ee-b2ed-4701-86ac-739a1016bab1
lightning-latest-web-1  | 13:05:02.495 request_id=GEE-AIwvQHJQgxAAAkKB [info] Sent 200 in 24ms
lightning-latest-web-1  | 13:10:30.900 request_id=GEE-TQQw3KcAXqwAAlBh [info] POST /i/511986ee-b2ed-4701-86ac-739a1016bab1
lightning-latest-web-1  | 13:10:30.903 request_id=GEE-TQQw3KcAXqwAAlBh [info] Sent 404 in 2ms

Edit: I am using the latest image in dockerhub

2

Lightning gives a 404 with a wrong password (which is weird because I use the same user/password in cURL) ,
I did not check directly because without password it give a proper 401 os I wrongly guess that 404 could only meant not found

I still don’t know what is the root cause, possible a malformed / unexpected header

3

@delcroip do you have webhook authentication configured by chance?

@midigofrank any ideas?

4

I used basic auth but the issue may come from CHT

do you have a way to see the request received ?

br

5

Hey @delcroip , unfortunately we do not have a way to see the requests.

And yes, you’re probably receiving a 404 because of invalid password/username in the request, maybe it’s something to do with encoding. We return 404 instead of 401 when credentials are invalid for security purposes.

To help debug, you can start a local http server and point CHT to it and get the full request

6

Hi,

Thanks for the reply, I deactivated the auth for the time being.

Regarding the 404 on password error I don’t think it is correct approach, it messed a lot with my troubleshooting, I think replying 401 will be better:

  • invalid endpoint ( add a server log message)
  • valid endpoint with invalid credential
  • valid endpoint requiring credential while no credential provided (already the case)
7

Oh super interesting. I really don’t know why you got different responses with the same CURL (that doesn’t seem right) but I know we’ve had lots of debate in the past about 4XXs.

I think the current desired behaviour is:

  1. If user is logged in or their credentials are incorrect, return a “401 Unauthorized” response.
  2. If the requested resource is not found, return a “404 Not Found” response.
  3. If user doesn’t have sufficient access rights to this resource, return a “404 Not Found” response.

We like to send back a 404 for both case 2 and case 3 so we don’t “disclose that such a resource exists” but if we’ve sent a 404 for case 1, maybe we’ve got to change something. What do you think?

8

I guess that somehow CHT is formatting the payload differently leading to this 404

We like to send back a 404 for both case 2 and case 3 so we don’t “disclose that such a resource exists” but if we’ve sent a 404 for case 1, maybe we’ve got to change something. What do you think?

Actually this statement is not correct because by doing a curl without credential for an endpoint requiring credential, I got a 401