Web-Apps

Veröffentlichen Sie das Skript als Web-App, wenn Sie eine Benutzeroberfläche dafür erstellen. Ein Skript, mit dem Nutzer beispielsweise Termine mit Mitgliedern eines Supportteams vereinbaren können, wird am besten als Web-App präsentiert, damit Nutzer direkt über ihren Browser darauf zugreifen können.

Sowohl eigenständige Skripts als auch an Google Workspace-Anwendungen gebundene Skripts können in Web-Apps umgewandelt werden, sofern sie die folgenden Anforderungen erfüllen.

Anforderungen für Web-Apps

Ein Skript kann als Web-App veröffentlicht werden, wenn es die folgenden Anforderungen erfüllt:

Es enthält eine doGet- oder doPost-Funktion.
Die Funktion gibt ein HTML-Service-HtmlOutput-Objekt oder ein Content-Service-TextOutput-Objekt zurück.

Anfrageparameter

Wenn ein Nutzer eine App aufruft oder ein Programm eine HTTP-GET-Anfrage an die App sendet, führt Google Apps Script die Funktion doGet aus. Wenn ein Programm der App eine HTTP-POST-Anfrage sendet, wird stattdessen doPost ausgeführt. In beiden Fällen stellt das Argument e einen Ereignisparameter dar, der Informationen zu beliebigen Anfrageparametern enthalten kann. Die Struktur des Ereignisobjekts wird in der folgenden Tabelle dargestellt:

Felder
`e.queryString`	Der Wert des Abfragestringteils der URL oder `null`, wenn kein Abfragestring angegeben ist name=alice&n=1&n=2
`e.parameter`	Ein Objekt mit Schlüssel/Wert-Paaren, die den Anfrageparametern entsprechen. Für Parameter mit mehreren Werten wird nur der erste Wert zurückgegeben. {"name": "alice", "n": "1"}
`e.parameters`	Ein Objekt, das `e.parameter` ähnelt, aber für jeden Schlüssel ein Array von Werten enthält {"name": ["alice"], "n": ["1", "2"]}
`e.pathInfo`	Der URL-Pfad nach `/exec` oder `/dev`. Wenn der URL-Pfad beispielsweise mit `/exec/hello` endet, lauten die Pfadinformationen `hello`.
`e.contextPath`	Wird nicht verwendet, ist immer ein leerer String.
`e.contentLength`	Die Länge des Anfragetexts für POST-Anfragen oder `-1` für GET-Anfragen 332
`e.postData.length`	Identisch mit `e.contentLength` 332
`e.postData.type`	Der MIME-Typ des POST-Bodys text/csv
`e.postData.contents`	Der Inhaltstext des POST-Texts Alice,21
`e.postData.name`	Immer der Wert „postData“ postData

Übergeben Sie Parameter wie username und age an eine URL wie die folgende:

https://script.google.com/.../exec?username=jsmith&age=21

So werden die Parameter angezeigt:

function doGet(e) {
  var params = JSON.stringify(e);
  return ContentService.createTextOutput(params).setMimeType(ContentService.MimeType.JSON);
}

Im vorherigen Beispiel gibt doGet die folgende Ausgabe zurück:

{
  "queryString": "username=jsmith&age=21",
  "parameter": {
    "username": "jsmith",
    "age": "21"
  },
  "contextPath": "",
  "parameters": {
    "username": [
      "jsmith"
    ],
    "age": [
      "21"
    ]
  },
  "contentLength": -1
}

Die folgenden Parameternamen sind vom System reserviert und sollten nicht in URL-Parametern oder POST-Bodys verwendet werden:

c
sid

Die Verwendung dieser Parameter kann zu einer HTTP-405-Antwort mit der Fehlermeldung „Sorry, the file you have requested does not exist.“ (Die von Ihnen angeforderte Datei ist nicht vorhanden) führen. Aktualisieren Sie Ihr Skript nach Möglichkeit, damit andere Parameternamen verwendet werden.

Skript als Web-App bereitstellen

So stellen Sie ein Skript als Web-App bereit:

Klicken Sie rechts oben im Skriptprojekt auf Bereitstellen > Neue Bereitstellung.
Klicken Sie neben „Typ auswählen“ auf „Bereitstellungstypen aktivieren“ > Web-App.
Geben Sie die Informationen zu Ihrer Web-App in die Felder unter „Bereitstellungskonfiguration“ ein.
Klicken Sie auf Bereitstellen.

Geben Sie die Web-App-URL für die Nutzer frei, die Ihre App verwenden sollen, sofern Sie ihnen Zugriff gewährt haben.

Web-Apps, die in einer Domain bereitgestellt werden, funktionieren nicht mehr, wenn ihr Inhaber zu einem gemeinsamen Laufwerk oder Konto in einer anderen Domain wechselt. Das kann korrigiert werden, indem der neue Inhaber oder Mitbearbeiter die Web-App in der neuen Domain noch einmal bereitstellt. Alternativ kann die Web-App auch wieder in die ursprüngliche Domain verschoben werden. In diesem Fall funktioniert sie für diese Domain wieder, ohne dass sie neu bereitgestellt werden muss.

Bereitstellung einer Web-App testen

So testen Sie Ihr Skript als Webanwendung:

Klicken Sie rechts oben im Scriptprojekt auf Bereitstellen > Bereitstellungen testen.
Klicken Sie neben „Typ auswählen“ auf „Bereitstellungstypen aktivieren“ > Web-App.
Klicken Sie unter der Web-App-URL auf Kopieren.
Fügen Sie die URL in Ihren Browser ein und testen Sie Ihre Web-App.

Diese URL endet mit /dev und kann nur von Nutzern aufgerufen werden, die Bearbeitungszugriff auf das Skript haben. In dieser Instanz der App wird immer der zuletzt gespeicherte Code ausgeführt. Sie ist nur für Tests während der Entwicklung vorgesehen.

Wenn Sie die Funktion Granular OAuth in der Web-App testen möchten, darf Ihr Projekt noch keine Autorisierungen haben. Verwenden Sie ScriptApp.invalidateAuth, um vorhandene Autorisierungen zu widerrufen. Bei allen Web-Apps, die bereits bereitgestellt sind und unter der Identität des aktiven Nutzers ausgeführt werden, ändern Sie das JSON-Feld executeAs im Manifest in USER_DEPLOYING.

Wenn Sie Webanwendungen bereitstellen, die als Entwickler ausgeführt werden sollen, sollten Sie sehr sorgfältig mit OAuth-Tokens umgehen, die über ScriptApp.getOAuthToken abgerufen werden. Mit diesen Tokens kann anderen Anwendungen Zugriff auf Ihre Daten gewährt werden. Übertragen Sie sie daher niemals an den Client.

Berechtigungen

Die Berechtigungen für eine Web-App hängen davon ab, wie Sie die App ausführen:

App als ich ausführen: In diesem Fall wird das Skript immer als Sie, der Eigentümer des Skripts, ausgeführt, unabhängig davon, wer auf die Web-App zugreift.
Anwendung ausführen als Nutzer, der auf die Webanwendung zugreift: In diesem Fall wird das Skript mit der Identität des aktiven Nutzers ausgeführt, der die Webanwendung verwendet. Bei diesem Berechtigungsansatz wird in der Webanwendung die E-Mail-Adresse des Skriptinhabers angezeigt, wenn der Nutzer den Zugriff autorisiert.

Um Missbrauch zu verhindern, gelten in Apps Script Beschränkungen für die Häufigkeit, mit der neue Nutzer eine Web-App autorisieren können, die als Nutzer ausgeführt wird. Diese Limits hängen unter anderem davon ab, ob das Veröffentlichungskonto Teil einer Google Workspace-Domain ist.

Zusammenarbeit an Web-Apps über eine geteilte Ablage Wenn eine Webanwendung in einer geteilten Ablage bereitgestellt wird und Sie die Option „Als Sie ausführen“ auswählen, wird die Webanwendung unter der Berechtigung des Nutzers ausgeführt, der sie bereitgestellt hat, da es keinen Skriptinhaber gibt.

Web-App in Google Sites einbetten {:#embed-web-app}

Für eingebettete Web-Apps gelten weiterhin Zugriffsberechtigungen, um böswillige Nutzung zu verhindern. Wenn Ihre eingebettete Web-App nicht zu funktionieren scheint, prüfen Sie, ob die vom Inhaber der Web-App und vom Domainadministrator festgelegten Berechtigungen ihre Verwendung zulassen.

Damit eine Web-App in Sites eingebettet werden kann, muss sie zuerst bereitgestellt werden. Außerdem benötigen Sie die Deployed URL (Bereitgestellte URL) aus dem Dialogfeld Deploy (Bereitstellen).

So betten Sie eine Web-App in eine Sites-Seite ein:

Öffnen Sie die Sites-Seite, auf der Sie die Web-App hinzufügen möchten.
Wählen Sie Einfügen > URL einbetten aus.
Fügen Sie die Web-App-URL ein und klicken Sie auf HINZUFÜGEN.

Die Web-App wird in einem Frame in der Seitenansicht angezeigt. Wenn Sie die Seite veröffentlichen, müssen Ihre Websitebesucher die Web-App möglicherweise autorisieren, bevor sie normal ausgeführt wird. Nicht autorisierte Web-Apps präsentieren dem Nutzer Autorisierungsaufforderungen.

Web-Apps und Browserverlauf

Wenn Sie eine Anwendung mit mehreren Seiten oder eine Anwendung mit einer dynamischen Benutzeroberfläche simulieren möchten, die über URL-Parameter gesteuert wird, definieren Sie ein Zustandsobjekt, das die Benutzeroberfläche oder Seite der App darstellt, und übertragen Sie den Zustand in den Browserverlauf, wenn der Nutzer durch Ihre App navigiert. Achten Sie auf Verlaufsereignisse, damit Ihre Web-App die richtige Benutzeroberfläche anzeigt, wenn der Nutzer mit den Browserschaltflächen vor- und zurücknavigiert. Wenn Sie die URL-Parameter beim Laden abfragen, kann Ihre App die Benutzeroberfläche dynamisch auf Grundlage dieser Parameter erstellen. So kann der Nutzer die App in einem bestimmten Zustand starten.

Apps Script bietet zwei asynchrone clientseitige JavaScript-APIs, mit denen Sie Webanwendungen erstellen können, die mit dem Browserverlauf verknüpft sind:

google.script.history bietet Methoden, die eine dynamische Reaktion auf Änderungen im Browserverlauf ermöglichen. Dazu gehören: Zustände (einfache Objekte, die Sie definieren) in den Browserverlauf einfügen, den obersten Zustand im Verlaufsstack ersetzen und eine Listener-Callback-Funktion festlegen, um auf Verlaufsänderungen zu reagieren.
Mit google.script.url können die URL-Parameter und das URL-Fragment der aktuellen Seite abgerufen werden, sofern sie vorhanden sind.

Diese Verlaufs-APIs sind nur für Web-Apps verfügbar. Sie werden nicht für Seitenleisten, Dialogfelder oder Add-ons unterstützt. Diese Funktion wird auch nicht für die Verwendung in Web-Apps empfohlen, die in eine Google-Website eingebettet sind.

Web-Apps Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.