How to share a google web app outside a domain preferably without creating a marketplace addon

Viewed 281

I'm new to apps scripting and have created a web app which is container bound to a spreadsheet.

The app provides an html form for patients to record blood pressure readings as they take them during the day. A query string on the web app url identifies the individual patient and puts their readings on a sheet, unique to them, as they submit them. The script is deployed as a web app (Publish -> Deploy as web app) and in my development account it works well.

Now I want to share the script with a few other accounts not in my domain, so that they can use it independently with their own patients, with their own web app url, with readings going onto their own spreadsheet and for me to be able to maintain the code centrally.

Researching this I see official addons are now provided through the Gsuite Marketplace. It appears my choices for 'sharing' are these:

  • create an officially reviewed addon and put it in the Gsuite marketplace but creating an addon for the world is not what I want to do (atm anyway!)
  • create a private addon for inside one domain but I want to share it with several domains
  • there appears to be a system for testing the script as an add-on, without publishing it and for sharing the testing but this is mentioned in the Gsuite addon docs but not mentioned in the Editor addon docs and anyway it's for testing.
  • share the spreadsheet in my account but then all readings end up on my spreadsheet
  • share the spreadsheet and code to other accounts so they can make a copy but then I can't maintain the code centrally

Can anyone suggest the best way to share this web app script so other accounts not inside my domain can use it independently but ideally so I can maintain the code centrally? Thank you.

1 Answers

I see two solutions here. One is to add a small amount of "user management" code to your tool. For example, include some query parameters on your base url such as email and authorization key. Set up a user-management spreadsheet with your list of users, mapping their email to a secret randomly generated authorization key, and their data spreadsheet ID.

When the script is accessed with a valid email/authorization_key combination, it then opens the relevant sheet and does its thing.

In this scenario, you would either need to have access to all the relevant spreadsheets (if the code is executing "as you"), or you would need to figure out a standardised file layout or approach that let your script locate the right files on each users drive (if the code is executing "as the user accessing the web app").

Another solution here is to use an Apps Script Library. Using a library would allow you to keep the bulk of the code in the library, while having lightweight "wrapper" code bound to each of the other users spreadsheets. This wrapper code would simply pass doGet/doPost, and any other function requests back to your library.

For example:

function doGet(e){
   return YourLibrary.doGet(e);
}

function doPost(e){
   return YourLibrary.doPost(e);
}

function aCallback(a,b,c){
   return YourLibrary.aCallback(a,b,c);
}

In the library scenario, each sheet and script can be private to the individual users, you would just need to walk them through the initial setup/deployment, and occasionally have them bump the library version and re-publish the web-app in their copies.

Related