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.
Related
I'm creating a google app using app maker. I want to integrate the Gmail API with the application. I went through it's guideline, but couldn't able to find any useful resource for my use case.
According to the guideline, google app script are supporting this, but I don't' know if it is possible to integrate the that it to the Google App Maker application.
Thanks in advance.
Update
I have done a bit of research and found that there's an inbuilt object called GmailApp which could be access via a server script. There are number of functions related to that. What I particularly looking for is to get/read email thread for the given subject and open it in a separate browser window, so the user will be able to interact with it (read the thread, reply..etc.)
I was able to integrate the Gmail API by going to
APP SETTINGS -> Advanced services and click on ADD SERVICE.
From there we could select Gmail API from the available services. As shown in the screen capture below.
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 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'
What options are there to pull a GApps user creation date?
I saw that the Admin SDK is capable of it, is it the only API capable of doing this? does any of the previous one also capable of?
If possible using GAS, it will be most excellent,
Thank you!
Indeed there does not seem be Google Apps Script services to pull the creation date. The DomainUser class provide interesting functionality for interacting with domain users (only for admins).
Using the Admin SDK with Google Apps Script using UrlFetchApp.addOAuthService is not as complex as it looks. You can read this answer which will throw some light on how you can use external API calls for certain Google API and bring the data to Google Apps Script.
The scope for the ADMIN SDK will be as follows
oAuthConfig1.setRequestTokenUrl("https://www.google.com/accounts/OAuthGetRequestToken
?scope=https://www.googleapis.com/auth/admin.directory.user.readonly");
Notice that in this case I have requested a readonly scope.
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.