Fix auth reset logic during redirects to different origin when _base_url set #8966
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #8966 +/- ##
=======================================
Coverage 98.28% 98.28%
=======================================
Files 107 107
Lines 34219 34271 +52
Branches 4057 4059 +2
=======================================
+ Hits 33631 33683 +52
Misses 415 415
Partials 173 173
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Dreamsorcerer
added
the
backport-3.11
Dreamsorcerer
added
the
bot:chronographer:skip
Backport to 3.11: 💚 backport PR created✅ Backport PR branch: Backported as #8976 🤖 @patchback |
…cts to different origin when _base_url set (#8976) **This is a backport of PR #8966 as merged into master (f569894).** --------- Co-authored-by: Maxim Zemskov <[email protected]> Co-authored-by: Sam Bull <[email protected]>
| if auth is None: | ||
|
|
||
| if auth is None and ( | ||
| not self._base_url or self._base_url.origin() == url.origin() |
There was a problem hiding this comment.
Calling .origin() is a bit expensive #7583 (comment)
We should probably cache self._base_url.origin() as self._base_url_origin` so we don't have to build it every time
There was a problem hiding this comment.
Probably could guard this with self._default_auth being set as well
What do these changes do?
Do not set ClientSession’s auth during redirects to a different origin when _base_url is set.
Are there changes in behavior for the user?
It might affect users who expect ClientSession to retain auth during redirects to different origins.
Is it a substantial burden for the maintainers to support this?
No.
Related issue number
#6764
#8953
Checklist
CONTRIBUTORS.txtCHANGES/foldername it
<issue_or_pr_num>.<type>.rst(e.g.588.bugfix.rst)if you don't have an issue number, change it to the pull request
number after creating the PR
.bugfix: A bug fix for something the maintainers deemed animproper undesired behavior that got corrected to match
pre-agreed expectations.
.feature: A new behavior, public APIs. That sort of stuff..deprecation: A declaration of future API removals and breakingchanges in behavior.
.breaking: When something public is removed in a breaking way.Could be deprecated in an earlier release.
.doc: Notable updates to the documentation structure or buildprocess.
.packaging: Notes for downstreams about unobvious side effectsand tooling. Changes in the test invocation considerations and
runtime assumptions.
.contrib: Stuff that affects the contributor experience. e.g.Running tests, building the docs, setting up the development
environment.
.misc: Changes that are hard to assign to any of the abovecategories.
Make sure to use full sentences with correct case and punctuation,
for example:
Use the past tense or the present tense a non-imperative mood,
referring to what's changed compared to the last released version
of this project.