Skip to content
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

Token keeps expiring after 7 days #28

Closed
NordicBlueNL opened this issue Oct 24, 2022 · 11 comments
Closed

Token keeps expiring after 7 days #28

NordicBlueNL opened this issue Oct 24, 2022 · 11 comments

Comments

@NordicBlueNL
Copy link

Hi,
Wonderful tool you have here! I am using it to sync my girlfriends work agenda to our shared Google Calendar. I just notice that my token keeps expiring every 7 days. I found out that it is because my "App" is in testing mode, tokens get revoked after 7 days (as seen here: https://stackoverflow.com/questions/66058279/token-has-been-expired-or-revoked-google-oauth2-refresh-token-gets-expired-i).

When I put my app into production, the authorize URL that ical_to_gcal_sync.py generates no longer works, When I put the app back to testing, the authorize URL works again.

Do you have any suggestions on how to keep your tool working after 7 days?

Thanks!

@andrewramsay
Copy link
Owner

I've noticed this happening as well. Not sure when it started but it never used to be a problem when I originally wrote the script, I think Google have made some relatively recent changes to their OAuth handling and part of that is this limited token validity.

I hadn't had a chance to find a solution for it yet - I just tried switching my own project to "Production" mode and while the URL seems to work it also seems to want to refresh the token on every single request now, so something isn't right! What was the issue with the URL you had? Was it just 404ing or did it display some kind of OAuth error message?

Anyway I'll try to have a look at this during the week sometime, it's been annoying me for a while and I'd like to get it properly fixed. I'll get back to you if I come up with anything that looks like it is working reliably.

@andrewramsay
Copy link
Owner

Managed to spend a bit of time looking into this today. I think I have things working again.

I started off with a fresh GCP project and OAuth credentials, not sure if this made any difference but the one I'd been using had been created years ago. Then I added a new "Desktop app" client ID and switched it to Production mode immediately.

After that I had to make some changes to the code, I think part of the problem has been that the various google-* packages in requirements.txt needed updating to newer versions, plus some tweaks to auth.py.

Now things appear to be working again - in particular I can see it's now successfully refreshing the OAuth token without any intervention like it's supposed to do.

The changes I've made are in #29 / this branch. Can you try that out and let me know if it works for you?

@NordicBlueNL
Copy link
Author

Hi!
Thanks for the swift response. I have some time tomorrow to test it, will let you know how it worked out!

@NordicBlueNL
Copy link
Author

I have updated to your updat_deps branch, removed the client_secret json and pckl, recreated the json with a fresh one after putting the app to production. I do receive a working authorization URL now, but after authorizing the app, it tries to do a callback to http://localhost:38995/ which gives a connection refused.

@NordicBlueNL
Copy link
Author

Ah I think I know what happens here, I am running the script on a server and opening the URL on my local computer...

@NordicBlueNL
Copy link
Author

I ran the project on my local machine, did the authorization workflow there, and copied the credentials json over to the server. Now it works :)

@andrewramsay
Copy link
Owner

andrewramsay commented Oct 30, 2022

I'm doing the same with a headless RPi. The simple workaround is to copy the URL it tries to redirect to and paste it into another SSH session on the server like this curl "redirect_url" so that localhost now refers to the correct device. That should allow the auth flow to complete as expected.

The alternative to this is to modify the parameters used by the call to run_local_server in auth.py. The docs show how you can pass it a host and port of your choosing for the redirect request. But this would naturally require your server to be visible to the internet, if it's on a LAN you'd need to configure port forwarding or something similar long enough to complete the auth flow.


Edit: oops didn't see your last comment, glad it's working! I'll leave these changes unmerged for a few more days in case anything breaks, but I haven't had any trouble yet.

@NordicBlueNL
Copy link
Author

I did try it with a curl on the server, but that failed for some reason, it was complaining about missing parameters. Oh well this did the job too :-). Let's see if it keeps working after a week. Thanks!

@andrewramsay
Copy link
Owner

Just checking back on this to see if it it's still working before I merge the changes?

It's been running smoothly for me for well over a week now so if it's still OK for you then hopefully that means it'll work for others too!

@NordicBlueNL
Copy link
Author

Still works like a charm on this side!

@andrewramsay
Copy link
Owner

Great will merge things into master then, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants