Resposta atual: os widgets HTML ou JavaScript arbitrários nativos não são uma funcionalidade publicada do ZimaOS
A proposta de 2026 solicitava widgets capazes de apresentar meteorologia, temporizadores Pomodoro, controlos do Pi-hole, memorandos, chat de IA e respostas de endpoints personalizados. Atualmente, o ZimaOS disponibiliza cartões de sistema integrados e uma OpenAPI para integrações, mas não documenta uma funcionalidade nativa que permita aos utilizadores colar HTML, CSS ou JavaScript arbitrários no painel inicial. Isto significa que o pedido continua a ser uma ideia de extensão do produto, enquanto os painéis externos orientados por API já são práticos atualmente.
Utilize a OpenAPI do ZimaOS para obter dados em vez de extrair dados do painel
O ZimaOS disponibiliza atualmente interfaces programáticas para armazenamento, utilizadores e serviços do sistema. Um painel personalizado pode chamar essas APIs e apresentar os seus próprios cartões sem depender de rotas privadas do frontend. A OpenAPI do ZimaOS é a superfície de integração estável.
O Homarr é o caminho mais rápido para um painel personalizado
Se o objetivo é a composição visual em vez da integração nativa, o Homarr já disponibiliza widgets de arrastar e largar, integrações, ícones e autenticação. A instalação Docker do Homarr fornece o método de implementação atual. Os requisitos das aplicações do ZimaOS ajudam a dimensionar o serviço adicional.
Porque é que o JavaScript arbitrário na interface de administração é altamente arriscado
Um widget capaz de executar JavaScript sem restrições dentro do painel NAS autenticado partilharia uma origem com privilégios elevados. Um widget malicioso ou com erros poderia ler dados, desencadear ações ou capturar informações da sessão. Se forem introduzidos widgets nativos, um design mais seguro teria de incluir sandboxing, âmbitos de permissões e uma API de widgets controlada.
Os riscos de cross-site scripting da OWASP explicam o problema central de segurança do navegador.
Prefira widgets só de leitura para monitorização
A utilização da CPU, a capacidade de armazenamento, as temperaturas, o tempo de atividade e o estado dos serviços são mais fáceis de disponibilizar com segurança do que ações de escrita. Um botão “desativar o Pi-hole” ou “reiniciar o contentor” requer autenticação, capacidade de auditoria e confirmação mais robustas, porque um clique no painel pode alterar o estado da infraestrutura.
Faça sondagens eficientes em vez de sondar a cada poucos segundos
A sondagem frequente cria pedidos constantes em segundo plano num servidor de baixo consumo. Para o armazenamento, as temperaturas e o estado dos serviços, 30–60 segundos são frequentemente suficientes. A meteorologia pode precisar apenas de vários minutos. Utilize atualizações orientadas por eventos sempre que possível, em vez de sondar tudo com o mesmo intervalo.
Mantenha os segredos no lado do servidor
Se um widget precisar de um token de API para meteorologia, Pi-hole, IA ou outro serviço, não o incorpore em JavaScript executado no navegador. Utilize um proxy de backend ou uma integração do lado do servidor que mantenha as credenciais fora do pacote do cliente. O proxy HTTPS do ZimaOS é útil quando os serviços precisam de acesso pelo navegador.
Utilize um painel separado quando quiser máxima liberdade
Um contentor de painel autónomo proporciona controlo total sobre o esquema e as integrações sem modificar o próprio ZimaOS. Também se adapta melhor às reformulações do frontend do ZimaOS. Para tarefas privilegiadas, crie uma ligação para o painel de administração nativo, em vez de clonar todos os controlos do sistema numa camada personalizada.
O que seria necessário num sistema nativo seguro de widgets
Uma implementação robusta teria de definir manifestos de widgets, permissões solicitadas, apresentação isolada, limites de frequência, compatibilidade de versões, segredos do lado do servidor e uma distinção clara entre widgets só de leitura e widgets que alteram dados ou o estado do sistema. A melhor parte do pedido original é a necessidade de uma superfície de extensão de primeira classe, não de uma execução de código sem restrições.
Faça o versionamento do seu painel personalizado separadamente do ZimaOS
Mantenha o código dos widgets, os adaptadores de API e a configuração num sistema de controlo de versões. Quando o ZimaOS alterar uma versão da API ou o fluxo de autenticação, poderá atualizar deliberadamente a integração, em vez de perder um script editado manualmente dentro de um contentor. Uma pequena camada de compatibilidade também permite que o mesmo painel comunique com vários dispositivos ZimaOS sem duplicar código.
Perguntas frequentes
Posso adicionar widgets personalizados diretamente ao ZimaOS?
Os materiais públicos atuais não documentam widgets HTML/JavaScript arbitrários definidos pelo utilizador como uma funcionalidade integrada.
Posso criar um painel do ZimaOS com a OpenAPI?
Sim. Os painéis externos podem utilizar as APIs suportadas do ZimaOS e apresentar os seus próprios widgets.
Os widgets devem guardar chaves de API em JavaScript?
Não. Mantenha as credenciais dos serviços no lado do servidor.
O Homarr é uma boa alternativa?
Sim, quando o objetivo é um painel personalizável em vez de modificar a interface nativa do ZimaOS.
Porque não permitir JavaScript arbitrário?
O painel é uma superfície de administração autenticada, pelo que os scripts sem restrições criariam riscos significativos de XSS e de privilégios.
