Cant get an OAuth token if my publish status is "In production"
Closed this issue · 20 comments
First up thanks for this project!
I have it working in testing mode but I cant get it working if I publish my app. Tried 3 times, following the instructions as per gmailctl init.
When visiting the authorisation link I get the following from the google oauth page:
Error 400: invalid_request
You can't sign in to this app because it doesn't comply with Google's OAuth 2.0 policy for keeping apps secure.
You can let the app developer know that this app doesn't comply with one or more Google validation rules.
Request Details
The content in this section has been provided by the app developer. This content has not been reviewed or verified by Google.
If you’re the app developer, make sure that these request details comply with Google policies.
redirect_uri: urn:ietf:wg:oauth:2.0:oob
Not sure if this is a recent change or not. I've followed the init instructions to the letter, from what I can tell. Any ideas?
This timing is wild @dabeeeenster, I ran into the same experience getting set up today. It does seem like permissions were locked down further since these instructions were written. Is there a way around it?
If not, is there a way to use this declarative tooling in a "manual mode"?
I'm thinking I:
- manually download my existing filters
- import them into gmailctl format
- export them
- manually delete existing filters & re-upload
I'd be fine with that level of manual work to get my filters under control. Thanks again for this inspiring project 🌟
@mbbroberg would we not be able to just grab a new token via oAuth if in development mode?
Amazing how hostile Google is to working with their APIs
I honestly don't know how to make this work reliably long term. I've tweaked the init instructions a number of times already, but it seems Gmail keeps changing their policies. Existing tokens still work (mine does), but I can see how this could affect new users.
I wonder how similar projects are handling this. I would be surprised if this was a change only in Gmail. It probably affects Drive as well.
Re #232 (comment): You can use gmailctl export to generate the XML to import manually in the Gmail settings.
What about actually going through the process of registering an official app? Has any other OS project done that before?!
I saw this in odeke-em/drive: https://github.com/odeke-em/drive/blob/bede608f250a9333d55c43396fc5e72827e806fd/src/init.go#L29-L30. There were some discussions in #48, but I can't see how to do this without using my own personal GCP account and potentially paying for API usage.
Besides having to worry about the GCP project itself (which I don't want to do), I also risk that other people use my API keys for other purposes, with my name attached to the consent screen.
Too many disadvantages for myself honestly.
FWIW, my token stopped working today. Worked fine last week.
Response: {
"error": "invalid_grant",
"error_description": "Bad Request"
}
Thank you for looking into this @mbrt.
Re #232 (comment): You can use
gmailctl exportto generate the XML to import manually in the Gmail settings.
If I'm following correctly, I'm with you on going from gmailctl to XML. I'm looking into going from XML to gmailctl format so I can use gmailctl as a sort of offline declarative editor. I'm hoping to avoid doing it all by hand 😬😅
@dabeeeenster Just tried running gmailctl init yesterday and ran into the same issue but I couldn't even get it working in testing. Did you do anything in addition to the init setup instructions to get it working.
I just tried creating a new project and starting from scratch this morning and had the same results. I did try putting a couple of my email accounts in the "Test Users" section of the app registration which seems to have fixed it for testing only. It also complained that the email I use for the GCP cannot be a test user but it still seems to have fixed it.
I followed the instructions - have the project set in dev mode and added the email address that I was using the project for.
Why do Google make this so painful?!
One workaround that would be helpful would be for the apply command to open the browser with the token refresh URL if it has expired. I don't run apply that often, and refreshing the token only takes 10 seconds or so. If it opened the browser, waited for the auth code and then applied the changes that would be good.
I would prefer if apply kept on applying changes and failed if the token has expired. Otherwise several commands may suddenly become interactive. I think there needs to be a better way to refresh the token though. Perhaps a separate command. Your workflow could become something like this:
gmailctl init --refresh-expired-token && \
gmailctl apply
Where the first command doesn't do anything if the token has not expired. Otherwise it prints out the refresh URL and waits.
ah ok great thanks
FTR, the command in #232 (comment) doesn't exist yet :)
OH. BOOO 🤣
I just tried with a fresh GCP project, new credentials and all that and I don't have any problem using gmailctl.
One weird thing that happened this time is that the redirect URL failed miserably, because it was pointing to http://localhost/, but I was able to copy the authorization code from a URL parameter.
In any case, I cannot reproduce the problem. Are you sure you're using the last version and the app is not submitted for verification?
Yep - using verification and not submitting the app to Google. It works, but my token expires in 7 days.
Yeah using test mode expires in a week and I'm testing that again (I'll need to wait a week). What I'm saying is that setting the app to "production", but without submitting for verification seems to work for me. In other words I can't reproduce the error in your first comment Error 400: invalid_request. Looks like it's not only you though, so I doubt you're doing something wrong.
In any case, I added a flag (called --refresh-expired) to make the refresh less painful. Now something like #232 (comment) should work, but let me know.
I'll keep this open, but I'm really tired of issues with the authentication changing every 6 months or so. Impossible to test automatically, hard to reproduce, etc.
I did get the redirect_uri: urn:ietf:wg:oauth:2.0:oob error and needed to convert my project to testing in https://console.cloud.google.com/apis/credentials/consent and add my email to test users.
Then doing gmailctl --refresh-expired did the trick. Thank you so much.
This issue is stale because it has been open for 30 days without activity.
This will be closed in 7 days, unless you add the 'lifecycle/keep-alive' label or comment.
Still haven't gotten around to fixing this.