Web-Apps

Wenn Sie eine Benutzeroberfläche für ein Skript erstellen, können Sie das Skript als Web-App veröffentlichen. Ein Skript, mit dem Nutzer beispielsweise Termine mit Mitgliedern eines Supportteams vereinbaren können, sollte am besten als Web-App präsentiert werden, 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 unten aufgeführten 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(e)- oder doPost(e)-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 Apps Script die Funktion doGet(e) aus. Wenn ein Programm eine HTTP-POST-Anfrage an die App sendet, wird stattdessen doPost(e) in Apps Script ausgeführt. In beiden Fällen stellt das e-Argument einen Ereignisparameter dar, der Informationen zu beliebigen Anfrageparametern enthalten kann. Die Struktur des Ereignisobjekts ist 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

Sie können beispielsweise Parameter wie username und age an eine URL übergeben, wie unten gezeigt:

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

Anschließend können Sie die Parameter so anzeigen:

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

Im obigen Beispiel gibt doGet(e) die folgende Ausgabe zurück:

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

Warnung :Die folgenden Parameternamen sind vom System reserviert und sollten nicht in URL-Parametern oder POST-Bodies 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 Script nach Möglichkeit, um andere Parameternamen zu verwenden.

Skript als Web-App bereitstellen

So stellen Sie ein Script als Web-App bereit:

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

Sie können die Web-App-URL mit den Personen teilen, die Ihre App verwenden sollen, sofern Sie ihnen Zugriff gewährt haben.

Hinweis :Web-Apps, die in einer Domain bereitgestellt werden, funktionieren nicht mehr, wenn ihr Eigentümer zu einem gemeinsamen Laufwerk oder einem 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:

1. Klicken Sie rechts oben im Skriptprojekt auf Bereitstellen > Testbereitstellungen.
2. Klicken Sie neben „Typ auswählen“ auf „Bereitstellungstypen aktivieren“  > Web-App.
3. Klicken Sie unter der Web-App-URL auf Kopieren.

4. 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.

Warnung :Wenn Sie Webanwendungen bereitstellen, die als Entwickler ausgeführt werden sollen, sollten Sie beim Umgang mit OAuth-Tokens, die über ScriptApp.getOAuthToken() abgerufen werden, sehr vorsichtig sein. Mit diesen Tokens können andere Anwendungen auf Ihre Daten zugreifen. Ü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.

Warnung :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.

Hinweis: Sie können mit anderen Nutzern an Web-Apps zusammenarbeiten, indem Sie eine Ablage für Teams verwenden. Wenn eine Webanwendung in einer geteilten Ablage bereitgestellt wird und Sie die Option „Als Sie ausführen“ auswählen, wird die Webanwendung mit den Berechtigungen des Nutzers ausgeführt, der sie bereitgestellt hat, da es keinen Skriptinhaber gibt.

Web-App in Google Sites einbetten

Warnung :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 die Verwendung zulassen.

Damit Sie eine Web-App in Google Sites einbetten können, muss sie zuerst bereitgestellt werden. Außerdem benötigen Sie die Bereitgestellte URL aus dem Dialogfeld Deploy.

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

1. Öffnen Sie die Sites-Seite, auf der Sie die Web-App hinzufügen möchten.
2. Wählen Sie Einfügen > URL einbetten aus.
3. 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 die Besucher Ihrer Website die Web-App möglicherweise autorisieren, bevor sie normal ausgeführt wird. Nicht autorisierte Webanwendungen zeigen dem Nutzer Autorisierungsaufforderungen an.

Web-Apps und Browserverlauf

Es kann sinnvoll sein, eine Apps Script-Web-App zu erstellen, die eine mehrseitige Anwendung oder eine Anwendung mit einer dynamischen Benutzeroberfläche simuliert, die über URL-Parameter gesteuert wird. Dazu können Sie ein Zustandsobjekt definieren, das die Benutzeroberfläche oder Seite der App darstellt, und den Zustand in den Browserverlauf übertragen, wenn der Nutzer in Ihrer App navigiert. Sie können auch auf Verlaufsereignisse warten, damit Ihre Web-App die richtige Benutzeroberfläche anzeigt, wenn der Nutzer mit den Browser-Schaltflächen vorwärts und rückwärts navigiert. 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 Web-Apps erstellen können, die mit dem Browserverlauf verknüpft sind:

• google.script.history bietet Methoden, mit denen dynamisch auf Änderungen am Browserverlauf reagiert werden kann. Dazu gehören: Zustände (einfache Objekte, die Sie definieren können) in den Browserverlauf einfügen, den obersten Zustand im Verlaufsstapel 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 in Google Sites eingebetteten Web-Apps empfohlen.