Wie baut man eine Chrome-Extension, die das Backend des eigenen SaaS teilt?
Indem man kein zweites Backend baut. MV3-Extensions können sich nicht auf HttpOnly-Cookies verlassen, daher authentifiziert man mit Workspace-API-Keys: Die Extension ruft die versionierte REST-API (/api/v1) der App mit einem Scoped Key auf, der an genau einen Workspace gebunden ist – und nutzt damit dasselbe Auth-Modell, dasselbe Tenant-Scoping und dieselbe Postgres-Datenbank wie die Web-App. Genau so ist supastacks MV3-Scaffold verdrahtet – Popup, Options-Seite, Background-Worker, Least-Privilege-Manifest.
Die Falle: ein zweites Backend, ohne es zu merken
Die übliche Geschichte: Ihr SaaS braucht eine Companion-Extension – um Seiten zu erfassen, Content zu clippen oder das Web zu annotieren. Sechs Monate später pflegen Sie zwei Auth-Systeme (Cookies fürs Web, irgendein handgebautes Konstrukt für die Extension), eine Parallel-API, die die Extension wirklich aufrufen kann, und eine Sync-Schicht, die zwei Datenbestände zusammenhält, die eigentlich einer sein sollten.
Nichts davon ist nötig. Die Extension ist nur ein weiterer Client Ihres bestehenden Produkts – sie braucht eine Credential, die sie halten kann, und eine API, die für programmatischen Zugriff gebaut ist. Der Fehler ist, nach einem neuen Backend zu greifen, statt die Workspace-API-Keys und die versionierte REST-Oberfläche zu nutzen, die ein ernstes SaaS längst hat.
Was Manifest V3 tatsächlich erlaubt
MV3 hat Background-Pages durch kurzlebige Service Worker ersetzt und Extensions auf Least Privilege gedrängt. Praktisch heißt das: kein persistenter In-Memory-State, kein Cookie-Kratzen für Session-Reuse (HttpOnly-Cookies sind ohnehin unerreichbar) und jede Host-Permission ist eine Frage im Web-Store-Review.
Die saubere Antwort ist das, was die Plattform längst bietet: eine Scoped Credential in chrome.storage.local und HTTPS-Calls an den Origin Ihrer App – angefragt als optionale Host-Permissions zur Setup-Zeit, nicht zur Installationszeit.
supastacks MV3-Scaffold: was bereits verdrahtet ist
supastacks apps/extension ist ein bewusst kleines, frameworkloses Manifest-V3-Companion – »Seite im Workspace speichern« – das das gesamte Muster Ende zu Ende zeigt. Es speichert Titel, URL und selektierten Text des aktiven Tabs als Workspace-Content-Entry über die versionierte REST-API POST /api/v1/content-entries.
Auth läuft über einen Workspace-API-Key (sk_…), der unter Settings → Developers erstellt wird: Der Key ist an genau einen Workspace gebunden, also ist die Bindung selbst die Workspace-Auswahl – der Key kann nirgendwo anders hinschreiben. Die Options-Seite persistiert App-URL und Key in chrome.storage.local, fordert Zugriff nur für diesen Origin an und verifiziert die Verbindung über GET /api/v1/workspaces/current.
apps/extension/
manifest.json MV3: service worker, least-privilege permissions
src/
background.js context-menu save + badge feedback
popup.html/.js capture UI — title, URL, selection, note
options.html/.js app URL + workspace API key setup
lib/
api.mjs versioned /api/v1 client (key auth)
capture.mjs active-tab + selection capture
config.mjs chrome.storage.local persistenceLeast Privilege per Default
Der Scaffold enthält nur die minimale Permission-Menge, die die Aufgabe braucht – wichtig für Web-Store-Review und Nutzervertrauen:
- Kein
tabs, kein<all_urls>, kein cookies/webRequest/declarativeNetRequest – ein Scaffold, der ehrlich deklariert, was er nicht braucht.
| Berechtigung | Wofür |
|---|---|
| activeTab | Titel/URL der aktuellen Seite nur bei Aufruf lesen |
| scripting | Selektierten Text im aufgerufenen Tab lesen |
| contextMenus | Rechtsklick-Speichern-Eintrag registrieren |
| storage | App-URL, API-Key und Workspace-Cache persistieren |
| optional_host_permissions | App-Origin wird zur Setup-Zeit angefragt – null Site-Zugriff bei Installation |
Vom Scaffold zum Companion Ihres Produkts
Rebranding ist eine Namensänderung im manifest.json; die Erweiterung ist der spannende Teil – und bleibt im selben Muster: Neue Capture-Typen rufen neue /api/v1-Endpoints mit demselben Key auf, und das aus der OpenAPI-Doku der App generierte typisierte @supastack/api-sdk hält Request-Shapes ehrlich.
Weil die Extension über dieselbe tenant-gescopte API liest und schreibt wie jeder andere Client, landen gespeicherte Seiten in denselben Postgres-Zeilen, die das Web-Dashboard auflistet – eine Datenbank, ein Auth-Modell, workspaceId-Scoping an genau einer Stelle erzwungen. Kein zweites Backend, kein Sync, kein Drift. Stufen auf der Pricing-Seite vergleichen.
| DIY-Zweit-Backend | supastack MV3-Scaffold | |
|---|---|---|
| Auth | Handgebautes Token-System neben Cookies | Workspace-API-Keys – dasselbe Auth-Modell wie Web |
| API | Neue Endpoints nur für die Extension | Versionierte /api/v1 + OpenAPI-typisiertes SDK |
| Daten | Zweiter Store + Sync-Logik | Dieselben Postgres-Zeilen, workspace-gescoped |
| Berechtigungen | Breiter Zugriff aus Bequemlichkeit | Least-Privilege-Manifest, review-freundlich |
FAQ: SaaS + Chrome-Extension auf einem Backend
Fragen, die Entwickler vor dem Launch eines Extension-Companions stellen:
- Warum ein API-Key statt des Session-Cookies des Nutzers?, HttpOnly-Cookies sind für Extension-JS per Design unsichtbar und MV3-Service-Worker sind kurzlebig – ein Scoped
sk_…-Key inchrome.storage.localist persistent, widerrufbar und an einen Workspace gebunden, sodass er nie tenant-übergreifend schreiben kann. - Funktioniert die Extension unter Firefox?, MV3 unterstützt dieselbe Oberfläche; der Code nutzt einen
browser ?? chrome-Namespace-Shim und wird Chromium-first entwickelt – Firefox ist also ein Port, kein Rewrite. - Ist sie direkt store-ready?, Es ist ein Produktionsmuster-Scaffold, kein Store-Submission – Sie benennen das Manifest um, fügen eigene Capture-Logik hinzu und schreiben den Listing-Text. Der schwere Teil (Auth, API, Tenant-Scoping) ist fertig.
- Welche Stufe enthält die Extension?, Das $299 Full Bundle liefert alle fünf Oberflächen – zwei Web-Engines, Expo, Tauri und den Extension-Scaffold – in einem Repo.