Token keeps expiring after 7 days about ical_to_gcal_sync

[andrewramsay]

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]

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]

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

[NordicBlueNL]

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]

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]

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]

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]

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]

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]

Still works like a charm on this side!

[andrewramsay]

Great will merge things into master then, thanks!