I want to set up a Push Notification using the Google Drive API and a web hook set up with Google Apps Script. I cannot figure out if this is possible or not.
The part of the steps that I can't figure out are the domain verification steps. I have a web app published with a doGet as below:
function doGet() {
refreshCandidates();
return HtmlService.createHtmlOutput('<b>google site verification</b>')
.addMetaTag('google-site-verification', 'Iu3xxxxxx')
.setSandboxMode(HtmlService.SandboxMode.IFRAME);
}
When I try to verify the url it gives me https://script.google.com/...ZS2/exec as an endpoint. But when I try to verify it is hitting https://script.google.com/...ZS2/exec/ and finding a completely different meta tag.
Has anyone successfully used the drive api and push notifications with google apps script? What am I missing?
Unfortunately, it is no longer possible to verify a GAS Web App url. Up until around August 2019, there was an option to "Register in Chrome Web Store" available under the "Publish" menu in the App Script editor. Back then any Web App so registered would have its URL automatically verified. However, that option has since been removed, and the verification methods available under the search console simply do not work for GAS Web App urls.
Furthermore, even when verification was feasible, it was not possible to effectively leverage Drive Push notifications since all relevant notification information is stored in HTTP headers which are not accessible from a GAS doPost() function.
Google Apps Script is no longer a viable platform for implementing Google API Push Notifications across most services (Gmail, Drive, Calendar, Admin Directory etc.). If you want to stick with Google's cloud offerings, there are alternatives you can explore. Google Cloud Functions is one such option.
UPDATE: Gmail leverages Cloud Pubsub for push notifications and this service has recently been updated to remove the need for domain verification for push endpoints. So, going forward its now possible to use GAS Web App URLs in this scenario.
Currently, it doesn't seem to be possible to verify webapp published using Google apps script using Google site verification from search console.
Feature request to Google was made. The issue can be tracked here. Consider adding a star(on top left) for Google to prioritize the issue.
Related
I want to set up a Push Notification using the Google Drive API and a web hook set up with Google Apps Script. I cannot figure out if this is possible or not.
The part of the steps that I can't figure out are the domain verification steps. I have a web app published with a doGet as below:
function doGet() {
refreshCandidates();
return HtmlService.createHtmlOutput('<b>google site verification</b>')
.addMetaTag('google-site-verification', 'Iu3xxxxxx')
.setSandboxMode(HtmlService.SandboxMode.IFRAME);
}
When I try to verify the url it gives me https://script.google.com/...ZS2/exec as an endpoint. But when I try to verify it is hitting https://script.google.com/...ZS2/exec/ and finding a completely different meta tag.
Has anyone successfully used the drive api and push notifications with google apps script? What am I missing?
Unfortunately, it is no longer possible to verify a GAS Web App url. Up until around August 2019, there was an option to "Register in Chrome Web Store" available under the "Publish" menu in the App Script editor. Back then any Web App so registered would have its URL automatically verified. However, that option has since been removed, and the verification methods available under the search console simply do not work for GAS Web App urls.
Furthermore, even when verification was feasible, it was not possible to effectively leverage Drive Push notifications since all relevant notification information is stored in HTTP headers which are not accessible from a GAS doPost() function.
Google Apps Script is no longer a viable platform for implementing Google API Push Notifications across most services (Gmail, Drive, Calendar, Admin Directory etc.). If you want to stick with Google's cloud offerings, there are alternatives you can explore. Google Cloud Functions is one such option.
UPDATE: Gmail leverages Cloud Pubsub for push notifications and this service has recently been updated to remove the need for domain verification for push endpoints. So, going forward its now possible to use GAS Web App URLs in this scenario.
Currently, it doesn't seem to be possible to verify webapp published using Google apps script using Google site verification from search console.
Feature request to Google was made. The issue can be tracked here. Consider adding a star(on top left) for Google to prioritize the issue.
I want to set up a Push Notification using the Google Drive API and a web hook set up with Google Apps Script. I cannot figure out if this is possible or not.
The part of the steps that I can't figure out are the domain verification steps. I have a web app published with a doGet as below:
function doGet() {
refreshCandidates();
return HtmlService.createHtmlOutput('<b>google site verification</b>')
.addMetaTag('google-site-verification', 'Iu3xxxxxx')
.setSandboxMode(HtmlService.SandboxMode.IFRAME);
}
When I try to verify the url it gives me https://script.google.com/...ZS2/exec as an endpoint. But when I try to verify it is hitting https://script.google.com/...ZS2/exec/ and finding a completely different meta tag.
Has anyone successfully used the drive api and push notifications with google apps script? What am I missing?
Unfortunately, it is no longer possible to verify a GAS Web App url. Up until around August 2019, there was an option to "Register in Chrome Web Store" available under the "Publish" menu in the App Script editor. Back then any Web App so registered would have its URL automatically verified. However, that option has since been removed, and the verification methods available under the search console simply do not work for GAS Web App urls.
Furthermore, even when verification was feasible, it was not possible to effectively leverage Drive Push notifications since all relevant notification information is stored in HTTP headers which are not accessible from a GAS doPost() function.
Google Apps Script is no longer a viable platform for implementing Google API Push Notifications across most services (Gmail, Drive, Calendar, Admin Directory etc.). If you want to stick with Google's cloud offerings, there are alternatives you can explore. Google Cloud Functions is one such option.
UPDATE: Gmail leverages Cloud Pubsub for push notifications and this service has recently been updated to remove the need for domain verification for push endpoints. So, going forward its now possible to use GAS Web App URLs in this scenario.
Currently, it doesn't seem to be possible to verify webapp published using Google apps script using Google site verification from search console.
Feature request to Google was made. The issue can be tracked here. Consider adding a star(on top left) for Google to prioritize the issue.
I've built a Google Sheets add-on that retrieves data from the Google Search Console API and writes it to the user's spreadsheets.
Since the Search Console API isn't available in the "Advanced Google services" section in Apps Script, I used the OAuth2 library available on GitHub, with the "https://www.googleapis.com/auth/webmasters.readonly" scope. It currently uses separate credentials in the Developer Console.
While the add-on works fairly well, when a user installs it for the first time, he/she has to authorize it using Google's OAuth process for certain scopes that are automatically detected in the script (managing spreadsheets, send emails, do external requests, and so on). After the authorization is completed, the add-on displays the usual add-on sidebar where the user has to do an additional OAuth process, this time for approving access to the Search Console API (via the OAuth2 library mentioned earlier).
My goal would be to include the Search Console scope in the initial OAuth process, so that users wouldn't need to go through the process twice. Unfortunately, the "Scopes" section in the Apps Script Project Properties isn't editable, so I cannot add that manually, and as far as I know there's no way to make it so it gets automatically detected.
Is there any way to do that? Would it make any difference if I were to use the Apps Script credentials for the OAuth2 library that I'm using to access the Search Console API (instead of having a separate set)?
Thanks!
As stated in this documentation, Google Apps Script can interact with APIs from all over the web. This guide shows how to work with different types of APIs in your scripts. You can use the UrlFetch service to make API requests directly.
Make requests to services with OAuth
APIs that act on behalf of a user usually require authorization, often using the OAuth protocol. Apps Script doesn't provide built-in support for the protocol, but there are open source libraries you can use to perform the OAuth flow and send the credentials with your requests:
OAuth1 for Apps Script: Compatible with OAuth 1.0 and 1.0a.
OAuth2 for Apps Script: Compatible with OAuth2.
This link might also help:
Making HTTP Requests Directly
If Google Authentication is desired for external applications, or a Google API is not available yet in this library, HTTP requests can be made directly.
The authorize method returns an authorized Guzzle Client, so any request made using the client will contain the corresponding authorization.
It is now possible to customize the OAuth list of a project via editing its manifest file: https://developers.google.com/apps-script/concepts/scopes
Google mentions that not all Google OAuth scopes are included (I haven't managed to find an exact list), but I've tested adding the Google Search Console scope and it seems to work fine.
I have a Google Apps Scripts web app and I would like to publish it on the Google Apps Market Place. I followed this instruction (https://developers.google.com/apps-script/guides/domain-wide-web-app) to properly setup the Apps Market Place SDK but I have some troubles.
To test installation flow I use the button in the setup page of the API, so :
My issue is if a user install the app as I allow personal install
The user validate rights and after he is redirected to the application. There I have an issue because the apps script web app request a "Offline access" in a new pop up.
=> I don't know how to add this scope because I don't find any scope for this need to add in the market place SDK setup.
What I found on stackoverflow is I probably have this message because on scope request by apps script web app there is the approval_prompt parameter set to force.
My question is how to avoid that and allow user to connect to app after validating scope on the apps market place ?
Thank you,
Stéphane
You can follow the List of Best Practices
Before you publish your Google App Marketplace application, please review the following list of best practices. Adhering to these best practices will help your application make it through the Google Apps Marketplace review process smoothly without you needing to make additional changes.
This document explain:
3: Define your scopes properly
All OAuth2.0 scopes must be defined in the Google Developer's Console, in the Scopes section of the Google Apps Marketplace SDK. This is essential in order to achieve one-click or zero-click SSO, as described in the following section.
According to this previous question, in the Admin Conso
I've added a few scripts to a Google Spreadsheet. One uses the Drive API. First time a person runs the script he has to manuallly enable access to Drive API and click on the link to Google Developer Console and enable access to Drive API.
There are about 100 people in my organisation who are going to use this spreadsheet and is there some way for me as a domain owner to enable Drive API so that the users don't have to do it by themselves?
/Magnus
Your users are going to have to create there own application in Google Developers console, and authenticate themselves.
Google Made a change recently that makes it against terms of service for you as a developer to give out your client id from Google developer console. So they will need to make there own. There is also no API that will let you automate this for them either.
As for authenticating that is the nature of authentication. Each user must give the application /or in this case script access to there account.
Sounds like you are doing everything correctly right now. It may seam time consuming but that is the way things have to be done.