-
-
Notifications
You must be signed in to change notification settings - Fork 420
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
OAuth2Session(..., auto_refresh_kwargs) and OAuth2Session.fetch_token(..., **kwargs) serve the same purpose #81
Comments
The However maybe your use-case can convince me otherwise, what did you have in mind where it would be better to pre-store the default args? |
I agree with what you've said, though likely it is my understanding of the OAuth2 spec that is lacking, but when would an automatic token refresh be different from a manual token fetch? I haven't worked with very many OAuth2 API's, so it's quite likely I simply haven't run into the scenario myself. |
An automatic refresh is not different from a manual refresh, but it is different from a token fetch in that you refresh your access token rather than obtaining an initial one. Using Google as an example.
As you see above the time point where a token is refreshed is very different from when it is first obtained. A refresh is invisible to the user. Obtaining a token (using fetch_token) is most often not. To get an access and refresh token you could use most of different flavours of the OAuth dance, e.g. webserver and installed together with The reason there is one |
Yes, I get how the flow works. My point was: Are there scenarios when you would give In my code, I pass the |
Ah, my apologies for the walls of text then :) It is probably often the same for authorization code grant but less likely when using resource owner password credentials grant. It is a balancing act here, for many it might work to just re-use them but for some it won't and might end up causing very confusing problems since some arguments get passed unexpectedly. I agree it feels redundant but I tend to opt for least surprise. There might be a nicer way to deal with it than appears to me now, feel free to point it out if you find it :) |
Totally fair. Also, my fault for not being clear. Thank you for taking the time to explain. :) Really enjoying the library so far, looking forward to contributing at some point! |
Looking forward to it :) One invaluable thing you might do as you get familiar is to point out shortcomings in the documentation in #48. |
Would be nice if they could be formally coupled. Such as maybe rename the former to something like
fetch_token_kwargs
, which can serve as the default if nofetch_token(..., **kwargs)
are provided as an override?The text was updated successfully, but these errors were encountered: