Skip to content

fix: Tolerate missing WWW-Authenticate-header (yahoo) - #718

Merged
tobixen merged 2 commits into
masterfrom
issue713-unprompted-basic-auth
Sep 21, 2026
Merged

tobixen merged 2 commits into
masterfrom
issue713-unprompted-basic-auth

Conversation

@tobixen

@tobixen tobixen commented Sep 21, 2026

Copy link
Copy Markdown
Member

RFC 7235 section 3.1 requires a 401 to name an authentication scheme. Yahoo Calendar omits it entirely, so _should_negotiate_auth never fires, build_auth_object() is never called, the credentials are never sent, and the bare 401 surfaces as AuthorizationError indistinguishable from a genuinely rejected password. This is a general fallback rather than a feature-flag-gated one, since a first-time connection to an unrecognised server has no compatibility hints to consult yet.

Added _should_attempt_unprompted_basic/_build_unprompted_basic_auth in base_client.py, wired into both the sync and async request loops. The guess fires once, only over TLS, and only when neither auth_type nor auth was already configured (either would already have taken effect before this code path is reached). #715 documents the same server behaviour via compatibility_hints for known servers; this is the general, unconditional counterpart for servers with no profile at all.

Prompt: Look into issue #713. Is it still relevant for the 3.3-series? [https://github.com//issues/713]
Followup-Prompt: I think we may want a general workaround that can work without features specified (but the check and feature-flag for it was created in a parallell branch/pull request). "if no www-auth header given, no auth_type set, and TLS in place, try out basic auth". (sic)

Reviewed-by: Tobias Brox tobias@redpill-linpro.com

tobixen and others added 2 commits September 21, 2026 18:43
RFC 7235 section 3.1 requires a 401 to name an authentication scheme.
Yahoo Calendar omits it entirely, so `_should_negotiate_auth` never
fires, `build_auth_object()` is never called, the credentials are never
sent, and the bare 401 surfaces as `AuthorizationError`
indistinguishable from a genuinely rejected password.  This is a general
fallback rather than a feature-flag-gated one, since a first-time
connection to an unrecognised server has no compatibility hints to
consult yet.

Added `_should_attempt_unprompted_basic`/`_build_unprompted_basic_auth` in base_client.py, wired into both the sync and async request loops. The guess fires once, only over TLS, and only when neither `auth_type` nor `auth` was already configured (either would already have taken effect before this code path is reached). #715 documents the same server behaviour via compatibility_hints for known servers; this is the general, unconditional counterpart for servers with no profile at all.

Prompt: Look into issue #713.  Is it still relevant for the 3.3-series? [#713]
Followup-Prompt: I think we may want a general workaround that can work without features specified (but the check and feature-flag for it was created in a parallell branch/pull request).  "if no www-auth header given, no auth_type set, and TLS in place, try out basic auth". (sic)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
@tobixen
tobixen force-pushed the issue713-unprompted-basic-auth branch from d686a91 to b5ad480 Compare September 21, 2026 16:44
@tobixen
tobixen merged commit 0136697 into master Sep 21, 2026
16 checks passed
@tobixen
tobixen deleted the issue713-unprompted-basic-auth branch September 21, 2026 21:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant