How to handle refreshing of access_token

[zeitmeister]

Hello!

I have a long running app that talks to ytmusic once a day and i recently switched to the oauth authentication method and after (i think) 18 hours i'm not authenticated anymore. the value in the expires_in property of the oauth.json translates to 18 hours. I see that there is a refresh_token in the .json file aswell but when i lookup the documentation for the auth flow (https://developers.google.com/youtube/v3/guides/auth/devices) it states that i need the client_id and client_secret aswell.
Does ytmusicapi have a way to refresh the access tokens or must i do it manually? And if that's the case, how do i get the client id and secret (I found them in the constants.py file but perhaps there's a better way that i'm not aware of yet)?

Thanks!
Simon

[sigma67]

It's built in.

ytmusicapi/ytmusicapi/auth/oauth.py

Lines 96 to 98 in 7c9455e

	if time.time() > token["expires_at"] - 3600:
	token.update(self.refresh_token(token["refresh_token"]))
	self.dump_token(token, filepath)

[zeitmeister]

Thanks for your reply. I've been trying to use the same YTMusic instance but looking at the constructor for that class it seems as the token is updated only in the constructor (only run once). There could of course be something that i don't get but should I instead instantiate YTMusic every time i use it? I.e is that the intended way to use ytmuscapi. Please let me know if i'm not making myself clear.

[sigma67]

Does your script run longer than the validity of the refresh token? I guess it's not really intended for something like long running web server backends. In that case you'd have to periodically refresh it manually.

Could of course also move the token validity check over into the send_request function.

[zeitmeister]

Yes, it runs longer that that, and every morning at 6 it updates a playlist. Moving the validity check to the send_request function would very much do it for me i think!

[zeitmeister]

Should I make a PR or are you on it?

[sigma67]

For sure, go ahead! Please keep the critical path impact down to the timestamp check, and even that only in case of oauth use.