Web Apps

If you build a user interface for a script, you can publish the script as a
web app. For example, a script that lets users schedule appointments with
members of a support team would best be presented as a web app so that
users can access it directly from their browsers.

URL parameters

When a user visits an app or a program sends the app an HTTP GET request,
Apps Script runs the function doGet(e). When a program sends the app an HTTP
POST request, Apps Script runs doPost(e) instead. In both cases, the e
argument represents an event parameter that can contain information about any
URL parameters. The structure of the event object is shown in the table below:

Fields

e.queryString

The value of the query string portion of the URL, or null if no query string is specified

name=alice&n=1&n=2

e.parameter

An object of key/value pairs that correspond to the request parameters.
Only the first value is returned for parameters that have multiple values.

{"name": "alice", "n": "1"}

e.parameters

An object similar to e.parameter, but with an array of values for each key

{"name": ["alice"], "n": ["1", "2"]}

e.contextPath

Not used, always the empty string.

e.contentLength

The length of the request body for POST requests, or -1 for GET requests

332

e.postData.length

The same as e.contentLength

332

e.postData.type

The MIME type of the POST body

text/csv

e.postData.contents

The content text of the POST body

Alice,21

e.postData.name

Always the value "postData"

postData

For instance, you could pass parameters such as username and age
to a URL as shown below:

Deploying a script as a web app

Save a new version of the script by
selecting File > Manage Versions, then Save New Version.

Select Publish > Deploy as web app.

Under Project version, select the version you just saved.

Under Execute the app as, select whose
authorization the app
should run with: your account (the developer's) or the account of
the user who visits the app (see permissions).

Under Who has access to the app, select who should be allowed
to visit it. The options differ depending on the type of account
you have, but they can include "Only myself", any member of your
domain, "Anyone" (with a Google account), or "Anyone, even anonymous".

Click Deploy.

Once you click Deploy, you'll see a new dialog with a message indicating
that your project has been successfully deployed as a web app.

This dialog provides two important URLs for your app:

The first is labeled Current web app URL and ends in /exec.
This URL is for the published version of your app, based on the
last version you saved and deployed.

The second is the link labeled latest code and ends in /dev.
This URL can only be accessed by users who have edit access to
the script. This instance of the app always runs the most recently
saved code — not necessarily a formal version — and is intended
for quick testing during development.

Warning: When deploying web apps to run as the developer, you should
exercise great care when handling OAuth tokens obtained through
ScriptApp.getOAuthToken().
These tokens can grant other applications access to your data — never
transmit them to the client.Note: Web apps deployed in one domain cease to function if their ownership
changes to a Team Drive
or account in a different domain. This can be corrected by having the
new owner or collaborator redeploy the web app in the new domain. Alternatively,
if the web app is moved back to its original domain the web app will start
functioning again for that domain without redeploying.

Permissions

The permissions for a web app differ depending how you choose to execute
the app:

Execute the app as me—In this case, the script always executes
as you, the owner of the script, no matter who accesses the web app.

Execute the app as user accessing the web app—In this case, the script
runs under the identity of the active user using the web app. This permission
approach causes the web app to show the email of the script owner when the user
authorizes access.

Warning: To prevent abuse, Apps Script imposes limits on the rate
at which new users can authorize a web app that executes as the user. These
limits depend, among other factors, on whether the publishing account is part of
a G Suite domain.Note: You can collaborate on web apps using
Team Drives.
When a web app in a Team Drive is deployed, choosing to "execute as you" causes
the web app to execute under the authority of the user that deployed it (since
there is no script owner).

Embedding your web app in Google Sites

Warning: Embedded web apps are still subject to access permissions to prevent
malicious use. If your embedded web app doesn't seem to be working, check to see
if the permissions set by the web app owner and the domain administrator allow
its use.

Embedding a web app in new Sites

In order to embed a web app, it must first be
deployed. You also
need the Current web app URL from the Deploy as web app dialog.

The web app appears in a frame in the page's preview. When you publish
the page, your site viewers may need to authorize the web app before it
executes normally. Unauthorized web apps present authorization prompts to
the user.

Embedding a web app in classic Sites

You can bind a script to a
classic Google Site in much the same way as a you
can bind a script to a Google Doc or Sheet. To create a bound script, visit
your site, click the gear icon
,
then select Manage site. On the Manage Site page, click Apps Scripts in the left nav, then the Add new script
button. This opens a new script in the Apps Script editor, where you can
code and deploy your web app.

You can also embed your web app in a page. You can bind the web app to the
Site or you can use any web app that you have the URL for. To embed a
web app into a Google Sites page, follow the steps below:

Open an existing Site for which you have edit access or create a new Site.

Navigate to the page in your Site where you want to embed the web app.

Click the edit icon, and then Insert > Google Apps Script.

Choose the script from the list that represents your web app. If your web
app is not bound to this Site, you can paste in the web app URL instead.

Click the Select button, choose the desired options from the next
dialog, and click Save.

Save your changes to the page and then you should see your web app embedded
in your Sites page.

Web Apps and Browser History

It can be desirable to have an Apps Script web app simulate a multi-page
application, or one with a dynamic UI controlled via URL parameters.
In order to do this well, you can define a state object to represent the app's
UI or page, and push the state into the browser history as the
user navigates your app. You can also listen to history events so that your web
app displays the correct UI when the user navigates back and forth with the
browser buttons. By querying the URL parameters at load time, you can have your
app dynamically build its UI based on those parameters, allowing the user to
start the app in a particular state.

Apps Script provides two asynchronous client-side JavaScript APIs to assist
with creating web apps that are linked to the browser history:

google.script.history
provides methods to allow dynamic response to browser history changes. This
includes: pushing states (simple Objects you can define) onto the browser
history, replacing the top state in the history stack, and setting a listener
callback function to respond to history changes.

google.script.url provides
the means to retrieve the current page's URL parameters and URL fragment, if
they are present.

These history APIs are only available to web apps. They are not
supported for sidebars, dialogs or add-ons. This functionality is also
not recommended for use in
web apps embedded in a Google Sites.