I am having this error
<"Access Not Configured. Gmail API has not been used in project ********* before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/gmail/overview?project=********* then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.">
I know Im having problem with the product ID. Couple of days ago my friend was running calendar API with my Pycharm and then he verified with his account with all the credentials. But I also created a new project>created new Credential. Downloaded the secret Json file and replaced with previous. I also checked the Json file, and the client ID was mine. But still Pycharm is still looking for that client ID which was my friends client ID. How do I resolve it?
I also tried opening new projects in Pycharm but still having same problem. I am new to python and Google APIs. If my question was too simple/obvious please pardon and help me out with the solutions.
The code I am using is given in this link, quickstart.py by Google developer page.
I finally solved the issue. I didn't enabled the gmail API from the console page. In the console page go to dashboard, next enable API and choose which API you want to enable. In my case it was Gmail.
Related
I have developed a desktop app that uses the Gmail API to download emails from only my own Gmail account. When I try to make the app "Internal", I am told that I cannot do so, because I am not a Google workspace user. So I started the verification process and went thru the first step - the domain verification process. After this step, I received this email from api-oauth-dev-verification#google.com:
Hi,
Thank you for your patience while we reviewed your project.
It looks like your app is only used by the people in your domain, so your project doesn’t need to be verified.
(Learn more about internal vs. public users).
Note: internal use and personal use are different.
Applications for Internal Use
If this is correct, please let us know by replying to this email. We'll then close your request, and you can update your project from public to internal by following these steps:
Sign-in to Google Cloud Console
Select the project ID: getEmails (id: getemails-354519)
Go to OAuth Consent Screen under APIs & Services
Go to User Type
Select Make Internal
Click Save**
But every time I try to make the app internal, I am prevented from doing so with the same message "Because you are not a Google Workspace user, you can only make your app available to external users".
How do I get around this Catch-22 situation? Any help would be greatly appreciated.
I have developed a desktop app that uses the Gmail API to download emails from only my own Gmail account. When I try to make the app "Internal", I am told that I cannot do so, because I am not a Google workspace user.
To set an app as internal you would need to have created that app on google cloud console using a user on your google worksapce domain. You can not set an app to internal if you have created it on a standard google gmail user.
So I started the verification process and went thru the first step - the domain verification process. After this step, I received this email from api-oauth-dev-verification#google.com:
If this app is being only used by you why would you want to verify it? verification is only needed when your going to have additional users then yourself.
But every time I try to make the app internal, I am prevented from doing so with the same message "Because you are not a Google Workspace user, you can only make your app available to external users".
Again you need to login and create the app from a user on your workspace domain not on a normal gmail user.
How do I get around this Catch-22 situation? Any help would be greatly appreciated.
If its single user, and you don't have a workspace domain. Don't verify it there's no need to.
I have a small personal-use only app that logs into a [throw away] gmail account to pull out an auth-token so it can then run a scheduled job (turning on/off my home cameras). Its dead simple and works, except that the app is in GCP TEST mode and it looks like the gmail auth expires in 7 days.
I highly doubt based on the below requirements that I can promote the app, and I dont want to publish it regardless. I tried GCP Support and wound up here. Im sure Im not the only person that has dealt with the 7 day expiration on a personal project. Any ideas?
If you check the documentation for oauth2#expiration
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.
The key hear is setting your project into production.
What you are showing in that image are requirements for application verification. You shouldn't have to go though verification for a single user app.
Try just setting it to prodcution and then wait a week and see if it still expires. It shouldn't
I highly doubt based on the below requirements
Unfortunately with the new security restrictions. I wouldn't doubt anything these days. They keep changing the rules.
My organization has a project that in the past has been able to function without issue with just the Google Drive and Google Picker APIs. Recently, (within the last few weeks?) I now get 403 errors that enabling the Admin SDK API is required.
Admin SDK has not been used in project XXXXXX before or is disabled. Enable it by visiting https://console.developers.google.com/apis/api/admin.googleapis.com/overview then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.
The project does make a request to the admin api (https://www.googleapis.com/discovery/v1/apis/admin/directory_v1/rest) along with its request to the drive api, but it's been doing that for years without needing to enable the Admin SDK API, and we've made no code changes there. Did something change recently around when the Admin SDK API is required?
(The project does have a service account, domain-wide delegation is enabled, etc.)
I just downloaded and install the WSO2 Identity Server 5.0.0 in CentoOS 7 to play with it. I created a JDBC DataStore instead of the H2 datastore that comes by default, also uncommented as default primary User Store the JDBC User Store, then run the Identity Server. When I go to the management/configuration/ users and roles/users or roles, the content area appears blank for both cases, users and roles.
So I must be doing something wrong or what?
I am login with the default credentials of admin/admin that the documentation says. The documentation also says that the user must be admin in order to manage users and roles, and I hope is the case as the links to manage users and roles appears but are not working, also in the console shows no error regarding this blank page.
Any directions on what I should go?
I can post the configuration I am using also, but is a very basic one, following the administration stated in the online documentation.
I found the problem, i was using Java 1.8, and saw an error compiling a JSP in the logs in the console in linux, so switch to Java 1.7 and now works fine.
WSO2 Identity server does not support Java 8.
I would like to have my application http://app.acquee.com/designer to accept a google account as a login. I found a bunch of libs for django but most work on top of existing Django authentication system that I do not use. I have my own set of user tables where I keep user info and privileges.
Any suggestion on how to integrate that with the Google Openid?
Seems I will have to do it manually using python-openid. Or could I use django-openid?
However, with the latter, I don't even know how to issue the discover command.
Regardless, I get stuck on google's step 5, sending a login authentication request (optionally with OAuth parameters) to the provided endpoint address. Can someone provide a sample request? is it a GET/POST? content?
Cheers
You can try https://launchpad.net/django-openid-auth - I'm using it in a commercial project, for both regular Google Accounts and Google Apps accounts. I remember that it was the most convincing one at the time I was doing a review, although I can't give you any details now due to my short memory. Anyway - it's working great.