You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Clearing authorization at the request level. #1004
Presumably you'd get the same behaviour with param, cookies, headers, or auth...
All of these default to None in the method signature, and python doesn't give us any way of determining when a user has passed an explicit auth=None vs. nothing being passed.
We could change the method signature to use open-ended keyword arguments, eg **kwargs, but that's far less descriptive, and then needs a bunch of extra checking.
Alternately we could change them to some sentinel empty value, so eg params = EMPTY, but that's a big awkward.
I'd be interested to know if you get similar behaviour in, say, requests, or if they're working around this being a bit of an awkward pattern in a graceful way?
We may well just want to make sure we're documenting this well, since it's a usability gotcha, even if it's not buggy.
Then at request time we can safely use None to signify "no auth"?
Only if we changed the .request() signature. Otherwise there's no way of determining the difference between the auth=None default, and an explicit auth=None passed by the user.
Looks like Requests behaves the same as we do for the specific case of auth, i.e. request(auth=None) is treated as "use the auth value on the session".
Eg we have timeout=None meaning "no timeout", so it'd be okay to assume that auth=None should mean "no auth".
Do we see an issue with considering using the same UNSET trick as we did for timeouts here (and maybe on other parameters such as headers, cookies, params)?
I was going to suggest .build_request()/.send() as a workaround, but as expected it won't work either — the "use client auth if request auth is None" logic is made inside .send().
Activity
lovelydinosaur commentedon May 29, 2020
Right, so...
Presumably you'd get the same behaviour with
param,cookies,headers, orauth...All of these default to
Nonein the method signature, and python doesn't give us any way of determining when a user has passed an explicitauth=Nonevs. nothing being passed.We could change the method signature to use open-ended keyword arguments,
eg **kwargs, but that's far less descriptive, and then needs a bunch of extra checking.Alternately we could change them to some sentinel empty value, so eg
params = EMPTY, but that's a big awkward.I'd be interested to know if you get similar behaviour in, say, requests, or if they're working around this being a bit of an awkward pattern in a graceful way?
We may well just want to make sure we're documenting this well, since it's a usability gotcha, even if it's not buggy.
yeraydiazdiaz commentedon May 29, 2020
I was thinking on init we could set
self.authto theUNSETtype ifauth=None. Then at request time we can safely useNoneto signify "no auth"?lovelydinosaur commentedon May 29, 2020
Only if we changed the
.request()signature. Otherwise there's no way of determining the difference between theauth=Nonedefault, and an explicitauth=Nonepassed by the user.florimondmanca commentedon May 29, 2020
Looks like Requests behaves the same as we do for the specific case of
auth, i.e.request(auth=None)is treated as "use theauthvalue on the session".But honestly I'd consider it a usability bug too.
Eg we have
timeout=Nonemeaning "no timeout", so it'd be okay to assume thatauth=Noneshould mean "no auth".Do we see an issue with considering using the same
UNSETtrick as we did for timeouts here (and maybe on other parameters such asheaders,cookies,params)?florimondmanca commentedon May 29, 2020
I was going to suggest
.build_request()/.send()as a workaround, but as expected it won't work either — the "use client auth if request auth isNone" logic is made inside.send().cansarigol commentedon May 30, 2020
Can we use a decorator to evaluate signature data before set?