Web-Zugriff auf Google Sheets

Der Zugriff auf Google Sheets richtet sich danach, welches Credential Sie mitbringen. Auf der veröffentlichten Website gibt es zwei gleichberechtigte Wege hinein: sich mit Google anmelden (OAuth) oder eine Service-Account-JSON-Schlüsseldatei wählen, die Ihr eigener Browser direkt verwendet. Der Unity-/lokale Pfad behält seinen maschinenlokalen Service-Account-Schlüssel unverändert bei.

Auf der veröffentlichten Website — OAuth, Lesen und Schreiben

Auf der veröffentlichten Website kann ein angemeldeter Nutzer Google Sheets sowohl lesen als auch schreiben, über sein eigenes OAuth-Token.

Geringstes Privileg. Die Anmeldung fordert Ihr grundlegendes Profil und dateibezogenen Tabellenzugriff (drive.file) an: Die App kann nur die Tabellendateien lesen und schreiben, die Sie ihr ausdrücklich geöffnet haben. Nichts Kontoweites — sie kann den Rest Ihres Drive weder auflisten noch durchsuchen, und eine Datei, die Sie ihr nicht geöffnet haben, bleibt unsichtbar.
Derselbe Core-Plan. Ein Schreibvorgang im Web durchläuft exakt denselben Core-Plan und dieselbe gemeinsame optimistische Sperrprüfung wie jeder andere Pfad — die Live-Tabelle wird unmittelbar vor dem Senden erneut geprüft, sodass eine Zelle, die ein Dritter nach Ihrem Import geändert hat, übersprungen und nie überschrieben wird. Nur die Transportschicht unterscheidet sich: Auf diesem Pfad trägt sie das OAuth-Bearer-Token.
Die ACL der Tabelle ist die letzte Instanz. SheetForge entscheidet nicht, wer schreiben darf — Google entscheidet das. Ein 403 von Google wird auf eine ehrliche Berechtigungsmeldung abgebildet statt auf einen Teil-Schreibvorgang, sodass eine Ablehnung sich wie eine Ablehnung liest.

Das OAuth-Token wird im Session-Cookie gehalten (ein JWT) und von Server-Aktionen verwendet. Die einzige Ausnahme ist Googles Dateiauswahl, die im Folgenden beschrieben wird: Sie ist ein Google-Widget, das auf der Seite läuft — ihr Öffnen übergibt der Seite deshalb ein kurzlebiges Zugriffstoken für Ihre eigene Sitzung.

Von der Dateiauswahl aus starten — Sie brauchen nie eine ID

Der angemeldete Tab beginnt mit Tabelle aus Google Sheets auswählen: Googles eigene Dateiauswahl öffnet sich über der Seite, Sie wählen die Tabelle, ihre ID landet im Panel, und der Import läuft von selbst. Die Auswahl ist auch das, was der App unter drive.file Zugriff auf diese Datei gewährt, sodass eine Geste beides erledigt. Eine Zeile Aktuelle Tabelle zeigt, worauf das Panel gerade zeigt.

Eine ID von Hand einzutippen funktioniert weiterhin — sie ist unter eine Klappe Erweitert: mit einer Tabellen-ID beginnen gewandert, und eine zuvor gespeicherte ID funktioniert weiterhin genau wie zuvor. Der ehrliche Haken steht direkt dabei: Google öffnet nur Dateien, die Sie mindestens einmal ausgewählt haben, daher wird eine ID für eine nie ausgewählte Datei abgelehnt, bis Sie sie auswählen (die Zeile Dateizugriff erlauben… unten deckt das ab).

Eine Datei für die App öffnen — einmalig

Unter drive.file wächst die Berechtigung Datei für Datei. Stößt die App auf eine Tabelle, auf die sie noch keinen Zugriff hat — eine unter Erweitert eingetippte ID, eine gespeicherte ID nach einem Kontowechsel —, öffnet sie in dem Moment, in dem sie auf den Berechtigungsfehler stößt, Googles eigene Dateiauswahl, in der diese Tabelle bereits vorausgewählt ist. Wählen Sie die Datei einmal aus, und der Import oder Push, den Sie gestartet haben, wird von selbst zu Ende geführt. Von da an verhält sich diese Tabelle genau wie immer.

Nichts vorab vorzubereiten. Sie erteilen den Zugriff nicht im Voraus — die Dateiauswahl erscheint genau dann, wenn sie gebraucht wird, ist auf die betreffende Datei vorausgewählt, und die von Ihnen angestoßene Aktion wird nach der Auswahl automatisch erneut versucht.
Erneutes Erteilen ist jederzeit griffbereit. Das Google-Panel hält eine Zeile Dateizugriff erlauben… bereit, die dieselbe Dateiauswahl jederzeit öffnet — zum Beispiel nach dem Wechsel zu einem anderen Google-Konto.
Eine ehrliche Grenze. Die Dateiauswahl ist ein Google-Widget, das auf der Seite läuft — solange sie in Benutzung ist, hält die Seite deshalb ein kurzlebiges Zugriffstoken (gültig für höchstens eine Stunde) für Ihre Sitzung, abgerufen von einem Same-Origin-Endpunkt, der Ihre Anmeldung voraussetzt. Das ist dieselbe Art von Vertrauen, die der Schlüsseldatei-Pfad weiter unten der Seite entgegenbringt — geschützt wird das durch die strikte Content-Security-Policy der App. Das Token wird weder gespeichert noch protokolliert.

Der Schlüsseldatei-Tab behält sein ID-Feld bewusst: Ein Service-Account hat keine angemeldete Browsing-Sitzung, mit der er auswählen könnte, sodass eine ID — mit der dem Konto geteilten Tabelle — dort der ehrliche Weg hinein bleibt.

Auf der veröffentlichten Website — eine Service-Account-Schlüsseldatei, signiert von Ihrem Browser

Der zweite Tab des Google-Panels nimmt eine Service-Account-JSON-Schlüsseldatei entgegen. Alles, was dieser Schlüssel tut, geschieht in Ihrem Browser:

Der Schlüssel erreicht den Server nie. Der Browser selbst signiert die Token-Anfrage und ruft Googles APIs direkt auf, sodass der Schlüssel, die signierte Anfrage, das Zugriffstoken und Ihre Tabellendaten die Server von SheetForge nie berühren. Die serverseitigen Service-Account-Routen bleiben auf der veröffentlichten Website geschlossen gesperrt (501), genau wie zuvor — dieser Pfad fügt eine Fähigkeit hinzu, ohne eine zu öffnen.
Das Merken des Schlüssels ist ehrlich darüber, was gespeichert wird. Wenn Sie sich entscheiden, den Schlüssel merken zu lassen, wird der Text der Datei sofort verworfen; was aufbewahrt wird — auf diesem Gerät, im Speicher des Browsers — ist ein Signierschlüssel, den Skripte auf der Seite verwenden, aber nie wieder auslesen können. Wer dieses Browserprofil öffnen kann, könnte ihn dennoch wiederherstellen — behandeln Sie dieses Gerät, als läge die Schlüsseldatei darauf. Schlüssel vergessen entfernt ihn sofort, in jedem offenen Tab, und die App bittet Google außerdem, das aktuelle Zugriffstoken zu widerrufen.
Derselbe Plan, dieselbe Prüfung. Lesen und Schreiben durchlaufen denselben Core-Plan und dieselbe Prüfung vor dem Senden wie die anderen Pfade.

Der Unity-/lokale Pfad

Der Service-Account-Schlüssel, den Unity und der lokale Entwicklungsserver verwenden, wird von einem maschinenlokalen Pfad gelesen und niemals hochgeladen oder gebündelt — derselbe Schlüssel, der in Google Sheets einrichten beschrieben wird; bewahren Sie ihn außerhalb von Assets/ und außerhalb des Repositorys auf. Das Repository enthält keine Zugangsdaten.

Dropdowns aktualisieren sich mit jedem Push

Nach einem Push aus der Web-App werden die Datenvalidierungs-Dropdowns der Tabelle automatisch neu geschrieben — jeder Tab in einem Batch, wobei das Dropdown einer Referenzspalte als Bereich über die Schlüsselspalte der Zieltabelle geschrieben wird, sodass es mitwächst, wenn Datensätze hinzugefügt werden. Eine Regel, die auf einen nicht existierenden Tabellen-Tab zielt, wird übersprungen und gemeldet. Das entspricht dem, was der Google-Push des Editors schreibt.

Welcher Pfad was tut

Wo Sie laufen	Google-Credential	Lesen	Schreiben
Unity / lokal	Service-Account-Schlüssel, von einem maschinenlokalen Pfad gelesen	Ja	Ja — chirurgisch präzise Zellschreibvorgänge, Struktur-Rewrite, Push
Veröffentlichte Website	Das OAuth-Token des angemeldeten Nutzers (`drive.file` — die für die App geöffneten Dateien)	Ja	Ja — derselbe Core-Plan + optimistische Sperrprüfung
Veröffentlichte Website	Eine von Ihnen gewählte Service-Account-Schlüsseldatei, direkt von Ihrem Browser verwendet	Ja	Ja — derselbe Core-Plan und dieselbe Prüfung; Anfragen gehen direkt von Ihrem Browser zu Google
Veröffentlichte Website	Serverseitige Service-Account-Routen	—	Geschlossen gesperrt (`501`)

Das Schreibverhalten ist überall identisch, wo es läuft, weil jeder Pfad sich den Core-Plan und die Prüfung vor dem Senden teilt. Nur der Transport — ein browser-signiertes Service-Account-Token, ein Pro-Nutzer-OAuth-Bearer oder der Schlüssel des lokalen Servers — ändert sich.