Fix digest auth dropping challenge fields with empty string values - #12097
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #12097 +/- ##
=======================================
Coverage 98.77% 98.77%
=======================================
Files 128 128
Lines 44892 44892
Branches 2383 2383
=======================================
Hits 44342 44342
Misses 390 390
Partials 160 160
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
Added a regression test for the empty realm case — it's a new parametrized entry in test_authenticate_scenarios that sends a challenge with realm="" and verifies the field is preserved in the parsed challenge dict. |
Backport to 3.13: 💚 backport PR created✅ Backport PR branch: Backported as #12107 🤖 @patchback |
Backport to 3.14: 💚 backport PR created✅ Backport PR branch: Backported as #12108 🤖 @patchback |
…challenge fields with empty string values (aio-libs#12107) **This is a backport of PR aio-libs#12097 as merged into master (4800115).** Co-authored-by: Kadir Can Ozden <101993364+bysiber@users.noreply.github.com>
What do these changes do?
Fix
DigestAuthMiddleware._authenticatesilently dropping challenge fields that have empty string values.The current code uses
if value := header_pairs.get(field):which relies on truthiness check. Since empty strings are falsy in Python, any challenge field with an empty value (e.g.,realm="") is excluded fromself._challenge. This causes_encode()to later raise aClientErrorcomplaining about a missingrealmparameter, even though the server did provide one.The
_encode()method already acknowledges that empty realm values are valid per RFC 7616 (Section 3.3 — the realm directive SHOULD contain the host name but MAY be empty). The fix changes the check tois not Noneso that only genuinely absent fields are skipped while empty values are preserved.Empty
noncevalues are still correctly rejected by the existing validation in_encode():Are there changes in behavior for the user?
Yes — digest authentication against servers that send
realm=""(or other empty challenge fields) will now work instead of raisingClientError.Is it a substantial burden for the maintainers to support this?
No, this is a single-line change.
Related issue number
N/A
Checklist
CHANGES/folder<issue_or_PR_number>.<type>.rst<type>is one offeature,bugfix,doc,removal,misc