mirror of
https://github.com/asterisk/asterisk.git
synced 2026-06-25 18:06:40 -07:00
29167b00dc
When an incoming request can't be matched to an endpoint, the "artificial" auth object is used to create a challenge to return in a 401 response and we emit a "No matching endpoint found" log message. If the client then responds with an Authorization header but the request still can't be matched to an endpoint, the verification will fail and, as before, we'll create a challenge to return in a 401 response and we emit a "No matching endpoint found" log message. HOWEVER, because there WAS an Authorization header and it failed verification, we should have also been emitting a "Failed to authenticate" log message but weren't because there was a check that short-circuited that it if the artificial auth was used. Since many admins use the "Failed to authenticate" message with log parsers like fail2ban, those attempts were not being recognized as suspicious. Changes: * digest_check_auth() now always emits the "Failed to authenticate" log message if verification of an Authorization header failed even if the artificial auth was used. * The verification logic was refactored to be clearer about the handling of the return codes from verify(). * Comments were added clarify what return codes digest_check_auth() should return to the distributor and the implications of changing them. Resolves: #1095