Mixing User Information and Private Information in Google Apps Script
Blog: Dave Thinking Aloud - David French
Going back to real coding. Well Google Apps Script anyway:)
Google Apps Script presents a few hurdles to an application designer if you want to work in the users’ context with information derived from your private documents or domain.I needed to work with
- some information derived from a document within my protected Google Apps document store (document private to me, within a domain where sharing documents outside domain is forbidden)
- the identity of user (may be outside domain but with a Google Account)
The identity of a user is available from Session.getActiveUser().getEmail() but this will fail in interesting ways unless the script is published to run under the user id of the user running the script.
The private document cannot be shared outside the domain, and in this particular case, access to the full document is restricted to one user within the domain. Scripted access to the information on the document must be done by a script published to run as that privileged user.
So we need two scripts that talk to each other. One doing the conversation with the user and one operating as me in the background. UrlFetchApp.fetch() provides the means for one script to call another with parameters. ContentService.createTextOutput() provides the means to set the response to a regular format like JSON or XML.
The following scripts demonstrate the mechanics.
1. The front end UI interaction with the users
This script must be deployed so that it is run as the script user and available to anyone. It will insist on a Google Account login and acceptance by user of exposure of the email id.
2. The back end interaction with private domain documents
This script must be deployed so that it is run as the script owner and available to anyone including anonymous users. This certainly should give you something to think about … this script can be run by anyone, from anywhere who knows the, admittedly difficult to guess, URI. Is the information returned very sensitive (not in my case)? Is the risk of exposure (very slight unless the developer leaves the source code lying around) balanced by the ease of implementation. Alternatives requires a whole authentication mechanism built into your app.
You may find that you cannot deploy a standalone script like this because of the “no sharing of documents beyond domain” restriction set up by administrator. In that case, put the script into a public site and deploy it from there.