-
Notifications
You must be signed in to change notification settings - Fork 123
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
Automatic Re-authentication #4
Comments
I am a little bit confused about:
Do you mean you have to open a browser and authenticate again ? |
No. If I let my program run for a while, eventually all requests return |
I get your point, I'll do it but I'm not sure when I could implement this feature since I am busy in doing something else :) |
That's understandable! I was more asking for confirmation that I hadn't missed an option in the API. |
The |
Just wanted to point out that Tekore already implements this, which is a Python library for the Spotify Web API. This can be helpful to see how the refreshing credentials are used in other libraries, and possibly to see how it's implemented. |
Thanks for your heads-up, I will take time to implement this feature after figure out how does it work in Tekore. |
It's actually pretty straigthforward. Whenever a request is made with the credentials, it checks if the token has expired, and in that case, it uses the refresh token to obtain a new access token. The usage is exactly the same as a regular token. This would mean that |
I get your point of Tekore's implementation. My original intution is using a daemon thread to scan the expire_time and refresh it before expired, but it's some kind of clumsy :) |
This is actually not as easy as I thought. Implementing this would mean that whichever method that fetches the token will have to check if it's expired, an in that case, refresh it. The complicated part comes in when we have to refresh the token: this is a mutable operation, so the method would be mutable as well, and thus propagate up until the endpoints, which would have to be mutable, too. In the end we'd have a fully mutable Spotify client, which would be much harder to use than an immutable one. But not sure if there's any way to fix this. Perhaps with cells or similars. |
My progress so farThere are a few approaches I've tried to avoid using features for configuring the different kinds of token: regular, cached, refreshing. It'd be better to consider alternatives before adding a new feature for a number of reasons, in my opinion:
The goal is to be able to configure a token as a combination of regular, cached, and refreshing. It shouldn't have any overhead if possible (so it has to happen at compile time), and it should be easy to understand and set up. ApproachesGeneric client over token typeI was initially thinking of using a base let client = ClientCredentialsSpotify::<CachedTokenHandler>::new(creds); A solution like this not only would make it possible to use different configurations of tokens with a single compiled However, not only this isn't exactly what we need, because the user could possibly want a both cached and refreshing token, but also the refreshing one would be quite complicated to implement inside a token handler component without knowing the authentication process that was followed. Not to mention that the initialization of the token handler would have to happen privately inside the client and not outside, because you have to pass it the HTTP client in the initialization, which the user doesn't have access to. The implementation of Configuration at runtimeA configuration at runtime is super easy to implement. But it has a few downsides:
NOTE: Huh turns out rustc can easily optimize the runtime overhead: https://godbolt.org/z/8Mb9K7, so it's less of a problem. Notice how the cached token part isn't included in the binary when using IDETsBack when I created a thread on r/rust for opinions for #173, I was sugested the new IDET pattern. It's an interesting take on extensible functionality as an alternative to features, but it seems quite complicated and not exactly what we need. If anyone wants to give it a try go ahead. All in all, I'm running out of ideas. I'd love more opinions on this, or otherwise we can just use conditional compilation with features -- which isn't that much of a problem anyway imo. Regarding my attempts, the only question we should consider is: are users really going to need different combinations of token configurations in the same program? |
As a summary now that #173 is done:
So what's left is just the second point, and adding checks when using the token in order to refresh it. |
Closing in favor of #223 |
Hey, thanks for the awesome library!
Is there a good way to automatically re-authenticate the
SpotifyClient
?Currently I create the client using the
OAuth
pattern that you have in the README.However, the authentication only lasts for an hour, and I have to restart my program in order to re-authenticate.
Is there a good way to do this automatically? Sorry if the question doesn't make sense, and thank you again for
rspotify
.The text was updated successfully, but these errors were encountered: