I want to develop a comercial App that works in connection with gmail, Google calendar and other Google products. For what I see, Google Apps Script would give me the required functionality but I cant seem to find the answer to a couple of deployment issues. In the Google Apps Marketplace article on Wikipedia I read this:
Google Apps Marketplace is a product of Google Inc. It is an online store designed to help people and organizations to discover, purchase, and deploy integrated cloud web applications that work with Google Apps (Gmail, Google Docs, Google Sites, Google Calendar, Google Contacts, etc.) and with third party software. Some apps are free, some are paid for. Apps are based on Google APIs or on Google Apps Script.
But then, looking into the Google Apps documentation, the only distribution mechanisms I find are the "Script Gallery" which implies access to the source code by the end user and no comercial transaction or Chrome Web Store which is bound to Chrome Browser, while what I intend to do is aimed at Google Sites or Google Apps users and perfectly Browser Agnostic. My questions are:
Can I bundle a Google Apps Script based App for sell in the Google Apps Marketplace ?
Can I deploy it without the end users having access to the source code?
The short answer is no. Google Apps Script imposes daily quotas on all of their GAS APIs. These quotas cannot be extended in any way, so it is not feasible to deploy this on a commercial scale. You should take a look at Google Apps Engine which gives much more flexibility for what you want to do.
There is a workaround that I did in the past. I had an installation script (that ran as me) that collected user properties and the actual app script that ran as the individual user and referenced the user properties collected. At the time I didn't set user script properties but you could do that to bypass the first install script I would think. When the user installed they would get an email with the user script link and then they would authorize it separately. Install link was distributed through Google Checkout (deprecated now) but you could do electronic distribution through another venue. Not a traditional app distribution process by any means but maybe it will spark an idea for your specific case.
#Javier - we too arrived at the same conclusion. Google Apps Marketplace (GAM) deployment is just one of the channels to reach businesses but its the un-extendable Google Apps quotas that cripples a commercial deployment of a Google Apps Scripts (GAS) based WebApp.
We tried listing our webapp based on GAS directly into GAM but it failed their SSO requirements as there was no way to use domain-wide delegation to authorize the GAS permissions for the end users if the webapp ran as "user accessing the web app".
While we migrate to a fully stand-alone application, we have managed to deploy a restricted version of the app to GAM indirectly using a GAE instance as a proxy.
Here is how its deployed.
The GAM listing links to a GAE proxy app.
GAE proxy does GAM compliant SSO and redirects all subsequent access to our publicly accessible webapp in "run as me" mode.
GAE proxy passes on any domain data authorized by the GAM client to the webapp.
Implement security mechanism to block unauthorized access to the public webapp and accept calls ONLY from the GAE proxy.
Our current customers (very small businesses/startups) are fine with this security model, but I am afraid this will not scale for larger commercial deployment.
#mrschwen: we too are considering your exactly approach in mind to mitigate quota issues in case our app gets wider adoption until we are forced to move out of the GAS space, even though the end users will be forced to authorize our scripts which will run as 'user accessing the web app'
Related
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 belongs IT Section which provides and distributes Google Apps and its related service in our company.
Our section has disabled Drive SDK in Google Apps admin Console because of our company policy.
However, many developers requested Drive api in our company.
So, we started registering developer's drive application in google apps marketplace to allow it.
After our registration, developers could use drive api.
However, recently our registration process has stuck in uploading on Chrome Web Store.
(*Please take a look at See step 8.)
Strictly speaking, chrome web store publishing status become rejected.
Moreover, we received app removal notification from chromewebstore-dev-support#google.com, like "Chrome Web Store: Removal notification for app name."
But we have no idea why this app has been rejected.
Here is our step we used to do.
In google developers console, I accessed api manager, and make drive api enabled.
Access drive SDK settings to register app icon and open URL, and save it.
*About open URL, we assume intranet FQDN is forbidden, so we set http://www.google.com as open URL.
In OAuth Concent, type service name and save it.
From api manager, enable Google Apps Marketplace SDK.
We set application name, description, register icon, support URL and drive api scope(https://www.googleapis.com/auth/drive) and save it.
Also prepare zip file for Chrome Web Store that includes manifest json and app icon.
*In manifest json, we wrote app name, description, web app URL(we set google sites) and write as domain-installable.
Upload zip file to chrome web store, icon, screeen shot, promotional tile images, set web site(we set google sites.), category and languages.
In the end, set Visibility option as private and everyone at mydomain.
After published both chrome web store and google apps marketplace, access to marketplace to find published app in our domain.
allow access of drive app in marketplace.
*Above processes were executed on September in 2015,
I believe developer console UI has been dramatically changed for now, so these steps might not match current steps.
### Questions ###
Considering above results, I would like to confirm things below.
I would like to confirm our steps above is correct or not for registering drive application in Google App Marketplace.
By referring Both Apps Marketplace Guides and Apps Marketplace Frequently Asked Questions, I could not find detail for specific steps.
I are wondering whether we must obtain or prepare domain for web application and it must be open on the web or not.
Are there any way to register in-house application in google apps marketplace without publishing on the web(wondering can use FQDN or not).
Is it possible to create Google Apps Marketplace App using service account or client application with Drive API?
Thank you in advance.
1. I would like to confirm our steps above is correct or not for registering drive application in Google App Marketplace. By referring Both Apps Marketplace Guides and Apps Marketplace Frequently Asked Questions, I could not find detail for specific steps.
You seem to have done the steps right. But just to be safe, you can check out Publish your App page on the apps marketplace documentation.
Steps to Publish the app
Go to the Chrome Web Store developer dashboard
Upload the zip file
Add a detailed description of your app for the Marketplace listing
Add your screenshot(s) and promotional tiles for the Marketplace isting
Add the URLs for your app's websites
Set the category, region, language(s), and other configuration details
Note: To publish a private, domain-only app, skip the next step and see the instructions below.
To publish a Marketplace app that is only visible within your own domain, do not use the listing review request form. Instead, on the developer dashboard, locate the "Visibility options" section and select "Private / Everyone at yourdomainname.com" before you publish
2. I are wondering whether we must obtain or prepare domain for web application and it must be open on the web or not.
I'm not sure what you mean by this question, but once the domain has been set and app published, the application will appear in the "For [your domain]" section in the Google Apps Marketplace available on admin.google.com
3. Are there any way to register in-house application in google apps marketplace without publishing on the web(wondering can use FQDN or not).
If you mean private company-wide application, I think Google Apps for Work can do this feature (this will incur additional charge to you though)
4. Is it possible to create Google Apps Marketplace App using service account or client application with Drive API?
Yes, Drive API also uses Domain-wide delegation of Authority in which the domain admin can grant 3rd party apps access to user data.
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.
Very related to this question: SSO, using Google Apps user database but I'm wondering how the user Nil started off with his OpenID script.
Could anyone give some background on this? I'm not very familiar with OpenID.
The Google Apps Marketplace Google Apps Platform Single Sign On overview provides all the information you need to get started. Since #Nils describes a Corporate Google Apps environment, it's very likely that this is where they went to start their implementation, since...
For in-house apps developed with the Google Apps extensions console, implementing Single Sign-On is a strongly recommended best practice.
You'll find background information and links to existing OAuth libraries in a variety of languages.
You should also look at the Google Identity Toolkit, which provides an API you can use to implement SSO for your web app, as well as a Javascript widget you can incorporate to make the task simple.
I had several questions regarding the usability of a "G Suite/Google Apps API." I would like to integrate some sort of document/spreadsheet/presentation management directly into an application I am building.
This service would have to have the ability to import and export to DOC/XLS/PPT/PDF etc..., so something like Feng Office (if you have ever heard of it), wouldn't suit this need.
For this purpose, I'm looking into such a thing exists. Before I would begin this endeavor, I was wondering:
Do the G Suite/Google Apps productivity tools allow documents/spreadsheets/presentations to be created, read, updated, and deleted all from a third-party application?
Would potential users have to have a Google account in order to use document/spreadsheet/presentation editor?
Could multiple users on my application access files under one Google account, if an account is needed at all?
Last, is it possible to skip a Google account, and let Google docs directly access and save documents on my local server?
Sorry for the crash list of questions, but if there is anyone who could help with these, it would be much appreciated.
spryno724
Yes.
Not necessarily, you can have your backend script sign in as you, or even better, an admin account set-up specifically for your app.
Yes, see #2.
I don't think so.
(Feb 2017) The executive summary is that you can do what you envision, either by using G Suite (formerly Google Apps) APIs or Google Apps Script. TL;DR below in response to your "mini-questions".
Yes; you can do it with...
Individual app REST APIs, i.e., Sheets API, Slides API, etc., or just the Google Drive API.
Keep in mind that the Drive API is used for file-oriented functionality (create, delete, import/export, etc.) while the individual APIs are for document-oriented functionality (editing, formatting, etc.)
To learn about using the REST APIs, see the first few videos in this playlist, specifically videos 2, 3, and 4 to start with
An alternative that's more like using "services" vs. APIs but that can also programmatically CRUD G Suite documents is Google Apps Script, server-side JavaScript apps that are hosted at and run in Google's cloud. If interested, I created an Apps Script intro video for you.
FYI, videos 5, 8, 22, and 24 from the playlist above are for Apps Script if you want to pursue that
Note that neither Google Docs nor Google Forms currently have REST APIs, but you can programmatically access them from Apps Script.
Yes, users need to have a Google account but they don't have to create a Gmail address. See this page on creating Google accounts without Gmail. (If they do want to create a Gmail address, then they can use this page instead.)
Yes, you would use the Drive API to set the sharing permissions with your users. See this page on Permissions and this one on Sharing for more info.
Not really; you need at least one Google account in order to access Google Drive where the files would be stored. You can, however, manage the files on your own, then import to Drive and export from Drive to allow your users to edit on your servers then push them back to Drive. For more info on import/export formats/MIMEtypes, see my answer to another SO question.