I have renew the token every 7 days #628
Comments
|
This is the actual error
For some reason the token expired |
|
I have the same issue: In documentation https://developers.google.com/identity/protocols/oauth2#expiration there is written: A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days. So the app needs to be published, which required google verification. :-( I have not found a solution yet. |
|
Duplicate of #611 ? |
|
@aristosv @dequeckerp If you are using KDE, add that url to kOrganizer, restart your system. |
|
I don't see how that iCal link can be used with gcalcli command line options. |
|
Per #611 , if we can figure out how to get gcalcli to pass a redirect_uri parameter to the Python Google OAuth2 module, it should be possible to publish the app without Google review and have longer-lasting tokens. I also filed an Ubuntu bug report at https://bugs.launchpad.net/ubuntu/+source/python-oauth2client/+bug/1983216 since it appears upstream is no longer maintaining the relevant library googleapis/oauth2client#317 |
|
Does the replacement library google-auth support the required functionality? |
|
I believe so. The deprecated Python module doesn't allow the code to specify redirect_uri. If we want to publish a web app in production rather than testing (thus extending the token expiration period), while foregoing Google verification, we need to be able to set redirect_uri. There's probably some way to hack around this in the existing gcalcli code but it wasn't something I could solve in a few minutes. |
|
I've published my own google app I was using to connect and I haven't had issues since. It gave an ugly warning about not being verified when logging in, but you can say you don't care :) |
How did you publish it? Doesn't it need to pass a manual review by Google? |
|
On Sun Apr 16, 2023 at 14:55, Feraidoon Mehri wrote:
> I've published my own google app I was using to connect and I haven't had issues since. It gave an ugly warning about not being verified when logging in, but you can say you don't care :)
How did you publish it? Doesn't it need to pass a manual review by Google?
No, it doesn't, unless you want to make that warning go away.
|
|
Likely fixed now that I merged #683. Please let me know if issues remain. Thanks! |
|
Was this fix merged to release 4.4.0? Today I wanted to use gcalcli, but got this error again: I followed the instructions how to create the token from the page here, but I got this error anyway. Is there something I can try to make it work for longer? |
|
Here is the error I got: |
|
Could you peek in your ~/.gcalcli_oauth file with a text editor and see if you can find "232867676714.apps.googleusercontent.com" in there, or a different ID before the .apps.…? (It may be a binary file but I think the "apps.googleusercontent.com" part should still be visible if you tell your text editor to open it anyway.) Also when this happens, does renewing with the same client_id/client_secret work, or do you have to update anything else? |
|
Yes, the .apps.googleusercontent.com string is present in the By renewing you mean to do: or do something elese? I tried this command, but gcalcli says that I should use one of the following commands (invalid choice error). |
|
But is the ID in there "232867676714", was my question.
I think on 4.4.0 |
|
No, there is no such string in the ID. Should I post it here? If I do list command, then it list my calendar. |
Nah, if it's not the old default then it would have to be one you set up. Just wanted to double check.
Ah, weird! I did feel like I saw auth treated differently for So IIUC you're saying that after you see this error...
? FYI I'll probably add a |
Looks like if there is a missing scope here it'd be I'll have to look into whether |
|
I ran the following: But why? |
|
Agreed that's weird. The errors are coming from deep in google_auth_oauthlib deps so there's not a lot of self-contained troubleshooting info, but it does seem like for one reason or another gcalcli really doesn't like something about this |
|
I created a clean project with OAuth and for now it is working. Let's see it in a week if it start behaving wrongly. |
|
Interesting today I ran the However when I do |
|
I also asked chatGPT about what to do in order to have non expiring secret. This is what I got To use the Google Calendar API with the Step 1: Create a Service Account
Step 2: Share Your Calendar
Step 3: Configure gcalcli
Step 4: Test gcalcliRun a command like the following to check if everything is working: gcalcli listYou should see your calendar events listed without the 7-day expiration issue. This setup allows Would this work? Is |
|
That config is utter nonsense it hallucinated afaik. Anyway everything about the token and whether it's valid is between Google and the client lib.
It'd be up to server implementation whether they instantly reject requests the moment the token expires. You can bet that it'll stop working very soon even if it's still somewhat working atm. |
|
🤦 now I see that my client that hasn't been expiring has "Publishing status" set to "In production", not "Testing". Mine says "Needs verification" still and I don't know why it wouldn't have the same limitations as others'. I did find this is exactly the expiration behavior they declare in their docs:
|
|
I checked a similar project's instructions https://www.home-assistant.io/integrations/google/#scenario-2-you-do-not-have-credentials-set-up-yet and they also said to use "In production". I can update the instructions, but I'll need someone else to confirm that's working properly for them. #809 reported hitting a "Error 400: invalid_request" for some reason related to that Production status. |
|
Yesterday the token expired, so I created a new one in the project with the Production status. When I checked the |
|
Excellent, thanks again for helping test. For snags with existing tokens, please check if you can redo any setup under the client after changing to "In Production" in case that helps anything. I'd imagine they at least try to invalidate existing tokens after that change. Wanted to ask @NuvolaF to see if that helps the snag they hit, too. |
|
So, today is 1 day after a week treshold. Even So the correct action would be to set the project to Production and after expiration generate another token. |
|
Or delete and reset the token immediately. But you can confirm now you have a token showing |
I've been experiencing the 7-day token expiration issue too, and have been following this thread. I set up a new project under Google Cloud Console, and switched it to Production, hoping to resolve the problem. But now when I try to authorise the application, I also receive an Error 400 - but in my case it's "Error 400: redirect_uri_mismatch" Full error details are: I've tried adding "http://localhost" as an Authorised redirect URI in the Google Cloud Console as suggested, but this hasn't helped. Not sure if I'm doing something wrong, or is there something else going on here? |
In fact the command But it is still working and the |
|
Ugh, shame it's getting weird, but at least we can repro issues easily. I'll try to bisect if there's something different about my setup that might be relevant. |
|
After following api-auth.md setup for 4.0.4-2 gcalcli (default for raspbian repo's) all worked fine on my headless rpi. But after a week gcalcli stopped working, i.e. gcacli list prompted to init. So started reading and in the end updated to 4.5.1. However my problem stayed, i.e. token expired after 7 days. The stack trace that followed on a "agenda" subcommand is as in a previous comment. The "list" subcommand just works. p.s. to recreate the renew token I moved $HOME/.local/share/gcalcli/oauth to oauth-old and used the "init" subcommand, in fact I also had to do this whenever the renew key expired, else the "init" subcommand found credentials to be "ok". Perhaps a reinit subcommand could be an improvement (or did I miss the correct way to do this)? |
|
Thanks! Still a little confused about the 4xx errors people are seeing but I should probably go ahead and update the doc with info we have so far.
|
|
My bad: with init, indeed it is working. I was using an ssh from a powershell to my rpi. The powershell isn't showing the "Ignore and refresh? [N]o [y]es:". Just the "Credentials already configured." is visible, and blancs are where the question should be. When I entered it just returned to the prompt (as No is the default). So now I retried it using an cygwin Xterm and this terminal did show the yes/no question. Probably the powershell doesn't like the ascii color codes... About the 4xx errors I'm not really surprised. I tried the remote server options on "init" (so with --noauth_local_server) but I couldn't get them to work. In the process tried to replace localhost with ip-addresses in the links given by gcalcli but that often resulted in 4xx errors :-). In the end, decided that is was probably firewall related on the rpi side and gave up. So I setup X11 (client side) on rpi and cygwin X11 server on my windows pc. Now I can do a "ssh -Y pi" and start a chromium on the pi to display on my pc. Which makes it possible to set gcalcli up using a local browser without using port forwarding. |
I deleted and recreated a new project under Google Cloud Console, set it to Production and managed to run the auth command successfully this time ... no 4xx errors. I don't know what I did differently, but the auth worked, and it's been over 7 days and gcalcli is still working. |
|
K awesome, so we still have some unknowns lurking but they probably have workarounds. I'll get the instructions updated and finally get this issue closed out! And if anyone does hit further 4xx issues with Production mode and is willing to follow up with Google support to understand what's happening there, we might be able to finally resolve the remaining unknowns. |
|
Could you help clarify some questions regarding the state of the art?
Thanks! |
Another question you didn't ask, but might wonder, is whether having it be "in review" after you switch to "Production" mode prevents it from working, and from what I've heard: no that shouldn't matter. Those answers will be in the auth doc once we confirm and get the doc updated. |
|
When I try to publish, gcalcli stops returning current date items and starts returning from a single date. Not sure if it's a gcalcli issue or the fact that google wants me to pay to truly publish. Has anyone else seen this behavior? |
|
That has to be something else going on, no way the behavior of gcalcli and the API depends on the state of your auth client. That only affects the permission for making the API requests. |
|
That's what I was figuring but as soon as I drop back to testing everything works as designed including the 7 day auth for testing apps. Are you guys running "paid" accounts when you set the app to published? |
|
@PMDant: I only use free version of Google services and it is working correctly. |
|
Hu I'll have to play with it some more and see. Thanks @ZaxonXP |
|
Hi, it seems I'm facing the same issue. is there a solution? how is anyone using gcalcli without having to recreate token after a few days? |
I've been using gcalcli successfully for several months now, without the need to recreate tokens. So it is possible! It took me a few attempts at getting my project set-up correctly, and I wasn't ever sure what I did differently. My project is set to production (which I believe is a key requirement), without the need for verification. From what I understand, various things can trigger the verification process, such as adding a logo, app domains or other branding, so leave your project as plain and simple as possible. Good luck! |
Hi, I will try according to your experience.
|
YES - Google Calendar API is enabled
NO - No scopes added |
Every 7 days, I start getting the following error in my log files
Basically the error is
code = input('Enter verification code: ').strip()To fix it, I have to create a new OAuth2 token and run this command again
gcalcli --noauth_local_webserver --client-id=$clientid --client-secret=$clientsecret --config-folder $parentdir/clients/$clientdir/auth agendaAnd then it lasts for 7 more days, and I have to repeat the process again.
What I'm I doing wrong here?
The text was updated successfully, but these errors were encountered: