Using v2 to get the survey list (https://api.surveymonkey.net/v2/surveys/get_survey_list) and receiving the error message "Client revoked access grant." Had just used the same script with the same access key and api key less than 2 months ago without incident. Have done nothing with the API in the account since, so not understanding why this is not working. This is on a Gold level account.
I know that it is close to the end of support date on v2 of the API, but my understanding is that date is December 1, 2016. Besides, I have another account in which I can run the same script (a Premium account with different key values, of course) and it is working for that account.
Yes this is more of a SurveyMonkey support question. There was a widespread issue where people using an invalid access token (generated with the API Console app, not their own app) stopped working.
You can just go to the SurveyMonkey developer portal and find your app. There will be an access token in the settings page. If your app isn't there, contact support to have it connected to your account.
Related
We are integrating the Gmail API with Integromat and, in order to avoid re-authorizing Integromat’s access every 7 days, we need to submit for Google verification.
Now the problem is that the Google verification wants to verify the ownership of each domain. I’m afraid this includes the integromat.com domain (since integromat.com is the authorized domain). That’s a problem since we don’t own the integromat.com domain and we therefore cannot verify domain ownership. Is there a contingency plan for this?
Besides, Google wants a YouTube video showcasing how the permission is being used, which is quite a silly requirement since our Integromat account is only used by us (obviously).
I wonder whether Make/Integromat has some official recommendation/help for this? I couldn’t find any so far.
Note that we are not using Google Workspaces so we can’t use Google’s "internal usage" option.
You have two issues here. The refresh token expiring, and your desire to submit your application for verification.
These are separate issues that are unrelated.
expiring token
Refresh token expiring after seven days is due to the fact that your application is currently in testing phase not that it has not been verified.
refresh token 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.
On the Ouath2 screen set the project to production and your tokens will stop expiring.
verification
Domain name:
If you are using a domain name either for redirect uri or hosting of your privacy policy. You must verify that you own this domain though though google search console. There is no way around this.
If you don't own integromat.com your not going to be able to use that. Host it on your own domain.
Gmail scopes are one of hardest scopes to be able to get an application verified for.
YouTube Video:
You will need to create a YouTube video and host it public so that the security team can verify what your application is doing and how it its intended to work. It is not a silly requirement. It is there to protect your users data.
Remember the third party security assessment for gmail scopes is going to cost you between 15k-75k dollars a year.
internal
As stated in exceptions-to-verification-requirements
Internal Use: The app is used only by people in your Google Workspace or Cloud Identity organization. Note that your app will not be subject to the unverified app screen or the 100-user cap if it's marked as Internal.
Your last line says.
Note that we are not using Google Workspaces so we can’t use Google’s "internal usage" option
You don't need to be verified. So you dont need to worry about the domain, or the youtube video.
We are facing the below screen when trying to authenticate to Google. The app that we are trying to authenticate is used for internal development and we did not publish it to our users.
Any idea why this occurs?
We faced an Unverified App screen before (as below) but now the authentication is disabled.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
Review is not required if you are only using it under the same account as created the project in Google Developer console. You can read more about this change in this help center article.
This change applies to Google OAuth web clients, including those used by all Apps Script projects. By verifying your app with Google, you can remove the unverified app screen from your authorization flow and give your users confidence that your app is non-malicious.
Once you have applied for verification it takes around a week and it should start working.
I found this thread some time ago when this happened to us in our development project on Google Cloud Platform.
You can use a project for development without verification. No problem on that. But there are some limitations (more information here and here). Basically, we reached the limit of 100 users accessing the application. It was strange because we were testing with few accounts (5-6) until we found that, if you uninstall and install the application again, it counts as a new user. We were testing incremental authorization, so we uninstalled/installed the application a lot of times and we reached the quota.
When you reach this limit, you will see the message "Sign in with Google temporarily disabled for this app" and only users from the organization where the project is hosted can access the application. So we couldn't make test with our accounts from a demo domain or our Gmail accounts.
The only solution available was to pass the OAuth verification form (even if you didn't want to publish the application), but there were problems to do it. For example, it was mandatory to remove http://localhost from valid OAuth URLs. And more problems related with development.
❗ But this has changed recently. I have accessed to OAuth credentials screen in Google Cloud Platform (APIs & Services > Credentials > OAuth consent screen) during this week and now the page it's different. Now you don't need to specify "Authorised JavaScript origins" and "Authorised redirect URIs", you just need to specify your scopes for Google APIs and the Authorised domains. Then, at the bottom of the page you will find the button "Submit Verification" and the process will start. You will also find some information on the right:
About the consent screen
The consent screen tells your users who is requesting access to their data and what kind of data you're asking to
access.
OAuth Developer Verification
To protect you and your users, your
consent screen may need to be verified by Google. Without
verification, your users will see an additional page indicating that
your app is not verified by Google.
Verification is required if
Your application type is public, and You
add a sensitive scope Verification may take several days to complete.
You will receive email updates as it's processed.
Saving without publishing
Even though your consent screen is
unpublished, you can still test your application with users with the
following limitations:
Sensitive scopes are limited to 100 grant requests before verification
is required
Users see an additional page indicating that your app is
not verified by Google.
To include "Authorised Javascript Origins" and Authorised redirect URIs" you need to go to APIs & Services > Credentials and there click on your OAuth 2.0 client ID. There will be a form where you can add them.
In our case it took 1 day to get a response from Google. In the email there were some instructions to pass the verification. We had to reply the email with a video uploaded on YouTube addressing the following points:
How does user sign-up on your app and grants access to the sensitive scopes requested in verification?
OAuth consent screen as seen by end users
How does your application use the requested scopes to provide services to developers?
A test account email and the password for us to test the user sign-up process and validate the project's functionality.
We recorded a video showing points 1, 2 and 3 and sent them a test account for number 4.
After 1 day, we got another response from Google confirming that our project had been verified.
So finally the problem was solved! 🙂
I hope this could help people in the same situation. It was really annoying for us.
I had to go into my Google Apps Script settings and turn on the "Google Apps Script API" setting. Then I tried again, and the script executed correctly without issue.
I had used the script a couple of weeks ago and it worked fine, so something must have happened between then and now that changed it... Not sure what caused that setting to switch.
I am working on a Google AdWords integration built on .NET, which was developed some time ago for API v201409. That version of the API has not been retired and I am now trying to migrate to the latest (v201506).
I have updated the Nuget package and it builds fine.
The account that I use to upload conversions is a manager account, with around 50 client accounts being managed by it.
When trying to upload conversions to some of the client accounts I am getting OfflineConversionError.UNAUTHORIZED_USER errors.
When I check the setup on the Google AdWords website everything looks fine. Each client account has the manager account set in the Account access settings.
I have used the ManagedCustomerService API to retrieve a list of client accounts that are managed by the manager account and it returns all accounts, including those that throw the error.
All refresh/access tokens appear to be working fine.
Has anyone experienced similar problems?
The OfflineConversionError.UNAUTHORIZED_USER is returned when you attempt to upload conversion data to an Adwords account other than the account that the click originated from.
If you have a manager account with multiple client accounts, make sure that the account ID is the correct one.
I have been struggled with Youtube API and now I am stuck.
What I did is:
create a project at google developers console(https://console.developers.google.com)
enabled "YouTube Data API v3"
generate api key of iOS.
access to https://www.googleapis.com/youtube/v3/search?key={API KEY}&part=id&q=soccer by web browser and got the error message
Am I missing something?
I have read many questions but I cannot solved yet.
In step 3 "generate API key for IOS", the comment on the Google Developer Console web page says
Use of this key does not require any user action or consent, does not grant access
to any account information, and is not used for authorization.
Clicking on the *Learn More" button, it says:
Use an API key when your application is running on a server and accessing one of the following kinds of data:
•Data that the data owner has identified as public, such as a public calendar or blog.
•Data that is owned by a Google service such as Google Maps or Google Translate. (Access limitations may apply.)
I think you need to use the OAuth process rather than the API Key. Click on Learn More in the OAuth section of the Developer Console web page to learn about using OAuth with Apple iOS.
To create oAuth credentials for iOS:
Create new Client ID / Installed Application / iOS
I know it sounds a bit elementary, but I solved this same problem by going back into Google developer, creating a whole new project, new API key, and then it worked. Google quirk??
I am looking for a way to upload videos from a web service to a handful of known Youtube accounts where I am the owner (have login/pw credentials).
For instance, when a video is uploaded to this site, it should also upload to Youtube accounts A, B, and C via the API.
It seems that Youtube has an old method for authenticating accounts in this manner called ClientLogin, but it has been deprecated as of 2012 and in fact no longer works consistently (significant problems popping up as of April 2013).
(ClientLogin Docs)
The new recommended protocol is oAuth 2.0 (docs), but I am struggling to understand - is this workflow possible via oAuth authentication? If not, is there an alternative that could handle it?
If you have a CMS account managing those account, you can do.
Currently service accounts are not working with Data API v3, hope to have them back soon.
Instead of storing login/pw credentials you must store login/refresh-token. With the refresh-token you request a new access-token after the current one has expired (after 1 hour)
The main difference is for the first time, you have to ask user to give you authorization via browser.
You can store the tokens and while you are calling the APi method, you can set the token in call to upload to that user's account