Risposta attuale: i widget HTML o JavaScript arbitrari nativi non sono una funzionalità pubblicata di ZimaOS
La proposta del 2026 chiedeva widget in grado di visualizzare il meteo, timer Pomodoro, controlli di Pi-hole, memo, chat AI e risposte da endpoint personalizzati. Attualmente ZimaOS pubblica schede di sistema integrate e un'API OpenAPI per le integrazioni, ma non documenta una funzionalità nativa che consenta agli utenti di incollare HTML, CSS o JavaScript arbitrari nella dashboard principale. Ciò significa che la richiesta rimane un'idea per un'estensione del prodotto, mentre le dashboard esterne basate sulle API sono già concretamente utilizzabili.
Usa l'OpenAPI di ZimaOS per i dati invece di effettuare scraping della dashboard
Attualmente ZimaOS espone interfacce programmatiche per l'archiviazione, gli utenti e i servizi di sistema. Una dashboard personalizzata può chiamare queste API e visualizzare le proprie schede senza dipendere da percorsi frontend privati. L'OpenAPI di ZimaOS è l'interfaccia di integrazione stabile.
Homarr è il percorso più rapido per una dashboard personalizzata
Se l'obiettivo è la composizione visiva anziché l'integrazione nativa, Homarr offre già widget drag-and-drop, integrazioni, icone e autenticazione. L'installazione Docker di Homarr indica il metodo di distribuzione attuale. I requisiti delle app di ZimaOS aiutano a dimensionare il servizio aggiuntivo.
Perché il JavaScript arbitrario nell'interfaccia di amministrazione è altamente rischioso
Un widget in grado di eseguire JavaScript senza restrizioni all'interno della dashboard NAS autenticata condividerebbe un'origine altamente privilegiata. Un widget dannoso o difettoso potrebbe leggere dati, eseguire azioni o acquisire informazioni di sessione. Se venissero introdotti widget nativi, un design più sicuro dovrebbe prevedere sandboxing, ambiti di autorizzazione e un'API per widget controllata.
I rischi di cross-site scripting descritti da OWASP spiegano il problema fondamentale della sicurezza del browser.
Preferisci widget di sola lettura per il monitoraggio
L'utilizzo della CPU, la capacità di archiviazione, le temperature, il tempo di attività e lo stato dei servizi sono più facili da esporre in sicurezza rispetto alle azioni di modifica. Un pulsante “disabilita Pi-hole” o “riavvia container” richiede autenticazione, tracciabilità e conferma più solide, perché un clic sulla dashboard può modificare lo stato dell'infrastruttura.
Esegui il polling in modo efficiente, invece di farlo ogni pochi secondi
Un polling frequente crea richieste costanti in background su un server a basso consumo. Per archiviazione, temperature e stato dei servizi, spesso sono sufficienti 30–60 secondi. Il meteo potrebbe richiedere solo alcuni minuti. Quando possibile, usa aggiornamenti basati sugli eventi invece di interrogare tutto allo stesso intervallo.
Mantieni i segreti sul lato server
Se un widget necessita di un token API per il meteo, Pi-hole, l'AI o un altro servizio, non incorporarlo nel JavaScript del browser. Usa un proxy backend o un'integrazione lato server che mantenga le credenziali fuori dal bundle client. Il proxy HTTPS di ZimaOS è utile quando i servizi devono essere accessibili dal browser.
Usa una dashboard separata quando vuoi la massima libertà
Un container dashboard autonomo offre il pieno controllo sul layout e sulle integrazioni senza modificare ZimaOS. Inoltre, resiste meglio ai redesign del frontend di ZimaOS. Per le attività privilegiate, collega la dashboard di amministrazione nativa invece di clonare ogni controllo di sistema in un livello personalizzato.
Cosa servirebbe per un sistema di widget nativi sicuro
Un'implementazione solida dovrebbe definire manifest dei widget, autorizzazioni richieste, rendering isolato, limiti di frequenza, compatibilità tra versioni, segreti lato server e una distinzione chiara tra widget di sola lettura e widget che modificano lo stato. L'aspetto migliore della richiesta originale è la necessità di un punto di estensione di prima classe, non l'esecuzione di codice senza restrizioni.
Gestisci la versione della dashboard personalizzata separatamente da ZimaOS
Conserva il codice dei widget, gli adattatori API e la configurazione in un sistema di controllo versione. Quando ZimaOS modifica una versione dell'API o il flusso di autenticazione, puoi aggiornare deliberatamente l'integrazione invece di perdere uno script modificato manualmente all'interno di un container. Un piccolo livello di compatibilità consente inoltre alla stessa dashboard di comunicare con più dispositivi ZimaOS senza duplicare il codice.
Domande frequenti
Posso aggiungere widget personalizzati direttamente a ZimaOS?
La documentazione pubblica attuale non descrive i widget HTML/JavaScript arbitrari definiti dall'utente come funzionalità integrata.
Posso creare una dashboard di ZimaOS con OpenAPI?
Sì. Le dashboard esterne possono usare le API supportate di ZimaOS e visualizzare i propri widget.
I widget devono memorizzare le chiavi API in JavaScript?
No. Mantieni le credenziali dei servizi sul lato server.
Homarr è una buona alternativa?
Sì, quando l'obiettivo è una dashboard personalizzabile anziché la modifica dell'interfaccia nativa di ZimaOS.
Perché non consentire JavaScript arbitrario?
La dashboard è un'interfaccia di amministrazione autenticata, quindi gli script senza restrizioni creerebbero gravi rischi di XSS e di escalation dei privilegi.
