-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
Persist Session-level CookiePolicy #4042
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persist Session-level CookiePolicy #4042
Conversation
|
@Lukasa we're going to need to merge in master to get the builds running in 3.0.0 again. I can do it but probably won't get to it till tomorrow. I'll need to strip out get_policy too because it's no longer needed either. |
d1349f7 to
e9ec3a2
Compare
Codecov Report
@@ Coverage Diff @@
## proposed/3.0.0 #4042 +/- ##
==================================================
+ Coverage 89.97% 89.98% +<.01%
==================================================
Files 15 15
Lines 1986 1987 +1
==================================================
+ Hits 1787 1788 +1
Misses 199 199
Continue to review full report at Codecov.
|
cec3900 to
66cc6e9
Compare
66cc6e9 to
009b80c
Compare
|
Alright, I've got the 3.0.0 branch hiccups worked out and I think this is ready for a peek. It's a trivial patch at this point with the flag gone and works across anything that looks like a cookielib.CookieJar. |
Lukasa
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, I really think this looks pretty good. @sigmavirus24 if this is cool by you then we should go ahead and merge this.
|
I'm confused. Does this mean that we expect people to set the cookie policy on the cookie jar directly or specify a new RequestsCookieJar with a policy that persists that way? I expected that this added an attribute to the Session that was used to create cookie-jars. Also, since we're adding this to 3.0.0, I'd like us to use a stricter cookie policy. The default one is very relaxed. |
|
@sigmavirus24, having the user either set it with There are two related problems this is trying to solve. The first is the CookieJar is currently copied on a redirect, but our This patch is going with the assumption that if you assign a CookieJar to the Session, we continue using everything that was set on that instance of the CookieJar. We could add an attr to the Session, but I think that's unneeded surface area at this point. If you don't like the policy on the CookieJar you're handing us, then simply change it back to the default with I agree with upping the default policy for the RequestsCookieJar but don't know if that's directly related to #3416. I'm happy to spin off another PR for that, unless you feel it needs to be done here. |
sigmavirus24
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm okay with this as is. Thanks for the explanation @nateprewitt. I probably should have waited for the caffeine to kick in this morning.
This is a followup for #3463, but refactored without the persistence flag which makes this a breaking change. Currently, Requests silently throws away any cookie policies set on a CookieJar as noted in #3416. This patch will preserve the CookiePolicy set on a session-level CookieJar for both redirected and subsequent requests.
The only caveat here is this won't work for a non-RequestsCookieJar since the policy isn't exposed publicly. We may want to add some documentation about this caveat but given the rarity of this case, the information in the issue tracker may be sufficient.