Réponse actuelle : les widgets HTML ou JavaScript arbitraires natifs ne sont pas une fonctionnalité publiée de ZimaOS
La proposition de 2026 demandait des widgets capables d’afficher la météo, des minuteurs Pomodoro, des commandes Pi-hole, des mémos, un chat IA et les réponses de points de terminaison personnalisés. ZimaOS publie actuellement des cartes système intégrées ainsi qu’une API OpenAPI pour les intégrations, mais ne documente pas de fonctionnalité native permettant aux utilisateurs de coller du HTML, du CSS ou du JavaScript arbitraire dans le tableau de bord d’accueil. La demande reste donc une idée d’extension du produit, tandis que les tableaux de bord externes pilotés par API sont déjà réalisables aujourd’hui.
Utilisez l’OpenAPI de ZimaOS pour les données au lieu d’extraire celles du tableau de bord
ZimaOS expose actuellement des interfaces programmatiques pour le stockage, les utilisateurs et les services système. Un tableau de bord personnalisé peut appeler ces API et afficher ses propres cartes sans dépendre de routes privées de l’interface. L’OpenAPI de ZimaOS constitue l’interface d’intégration stable.
Homarr est la solution la plus rapide pour créer un tableau de bord personnalisé
Si l’objectif est la composition visuelle plutôt que l’intégration native, Homarr propose déjà des widgets glisser-déposer, des intégrations, des icônes et une authentification. L’installation Docker de Homarr fournit la méthode de déploiement actuelle. La page consacrée aux exigences des applications ZimaOS aide à dimensionner le service supplémentaire.
Pourquoi le JavaScript arbitraire dans l’interface d’administration présente un risque élevé
Un widget capable d’exécuter du JavaScript sans restriction dans le tableau de bord NAS authentifié partagerait une origine dotée de privilèges élevés. Un widget malveillant ou défectueux pourrait lire des données, déclencher des actions ou récupérer des informations de session. Si des widgets natifs sont introduits, une conception plus sûre devrait prévoir une sandbox, des niveaux d’autorisation et une API de widgets contrôlée.
Les risques de script intersite expliqués par l’OWASP mettent en évidence le problème fondamental de sécurité des navigateurs.
Privilégiez les widgets en lecture seule pour la surveillance
L’utilisation du processeur, la capacité de stockage, les températures, la disponibilité et l’état des services sont plus faciles à exposer en toute sécurité que les actions d’écriture. Un bouton « désactiver Pi-hole » ou « redémarrer le conteneur » nécessite une authentification, une traçabilité et une confirmation renforcées, car un clic dans le tableau de bord peut modifier l’état de l’infrastructure.
Effectuez des interrogations efficaces plutôt que toutes les quelques secondes
Des interrogations fréquentes génèrent constamment des requêtes en arrière-plan sur un serveur peu énergivore. Pour le stockage, les températures et l’état des services, 30 à 60 secondes suffisent souvent. La météo peut ne nécessiter qu’une mise à jour toutes les quelques minutes. Utilisez autant que possible des mises à jour événementielles plutôt que d’interroger tous les services au même intervalle.
Conservez les secrets côté serveur
Si un widget a besoin d’un jeton d’API pour la météo, Pi-hole, l’IA ou un autre service, ne l’intégrez pas au JavaScript du navigateur. Utilisez un proxy dorsal ou une intégration côté serveur qui conserve les identifiants en dehors du paquet client. Le proxy HTTPS de ZimaOS est utile lorsque les services doivent être accessibles depuis le navigateur.
Utilisez un tableau de bord distinct pour bénéficier d’une liberté maximale
Un conteneur de tableau de bord autonome offre un contrôle total de la disposition et des intégrations sans modifier ZimaOS lui-même. Il résiste également mieux aux refontes de l’interface de ZimaOS. Pour les tâches privilégiées, renvoyez vers le tableau de bord d’administration natif plutôt que de reproduire toutes les commandes système dans une couche personnalisée.
Ce qu’un système de widgets natif sécurisé devrait prévoir
Une implémentation solide définirait des manifestes de widgets, les autorisations demandées, un rendu isolé, des limites de débit, la compatibilité des versions, les secrets côté serveur et une distinction claire entre les widgets en lecture seule et ceux qui modifient l’état. Le meilleur aspect de la demande initiale est le besoin d’une interface d’extension de premier ordre, et non l’exécution de code sans restriction.
Versionnez votre tableau de bord personnalisé séparément de ZimaOS
Conservez le code des widgets, les adaptateurs d’API et la configuration dans un système de gestion de versions. Lorsque ZimaOS modifie une version d’API ou un flux d’authentification, vous pouvez mettre à jour l’intégration de manière délibérée au lieu de perdre un script modifié manuellement dans un conteneur. Une petite couche de compatibilité permet également au même tableau de bord de communiquer avec plusieurs appareils ZimaOS sans dupliquer le code.
FAQ
Puis-je ajouter des widgets personnalisés directement à ZimaOS ?
La documentation publique actuelle ne présente pas les widgets HTML/JavaScript arbitraires définis par l’utilisateur comme une fonctionnalité intégrée.
Puis-je créer un tableau de bord ZimaOS avec l’OpenAPI ?
Oui. Les tableaux de bord externes peuvent utiliser les API ZimaOS prises en charge et afficher leurs propres widgets.
Les widgets doivent-ils stocker les clés API dans le JavaScript ?
Non. Conservez les identifiants des services côté serveur.
Homarr est-il une bonne alternative ?
Oui, lorsque l’objectif est un tableau de bord personnalisable plutôt que la modification de l’interface native de ZimaOS.
Pourquoi ne pas autoriser le JavaScript arbitraire ?
Le tableau de bord est une interface d’administration authentifiée ; les scripts sans restriction créeraient donc d’importants risques liés aux attaques XSS et aux privilèges.
