Obecna odpowiedź: natywny arbitralny HTML ani widżety JavaScript nie są opublikowaną funkcją ZimaOS
Propozycja z 2026 roku dotyczyła widżetów, które mogłyby wyświetlać pogodę, minutniki Pomodoro, elementy sterujące Pi-hole, notatki, czat AI i odpowiedzi z niestandardowych punktów końcowych. Obecnie ZimaOS udostępnia wbudowane karty systemowe oraz OpenAPI do integracji, ale nie dokumentuje natywnej funkcji umożliwiającej użytkownikom wklejanie dowolnego kodu HTML, CSS lub JavaScript do pulpitu głównego. Oznacza to, że prośba nadal pozostaje pomysłem na rozszerzenie produktu, podczas gdy zewnętrzne pulpity oparte na API są już dziś praktycznym rozwiązaniem.
Używaj OpenAPI ZimaOS do pobierania danych zamiast skrobania pulpitu
Obecne ZimaOS udostępnia programistyczne interfejsy do obsługi pamięci masowej, użytkowników i usług systemowych. Niestandardowy pulpit może wywoływać te interfejsy API i renderować własne karty bez zależności od prywatnych tras frontendu. OpenAPI ZimaOS jest stabilnym interfejsem integracyjnym.
Homarr to najszybsza droga do niestandardowego pulpitu
Jeśli celem jest kompozycja wizualna, a nie natywna integracja, Homarr już oferuje widżety typu „przeciągnij i upuść”, integracje, ikony i uwierzytelnianie. Instalacja Homarr w Dockerze to obecnie zalecana ścieżka wdrożenia. Wymagania aplikacji ZimaOS pomagają dobrać zasoby dla dodatkowej usługi.
Dlaczego dowolny JavaScript w interfejsie administracyjnym jest obarczony wysokim ryzykiem
Widżet, który może wykonywać nieograniczony kod JavaScript w uwierzytelnionym pulpicie NAS, działałby w ramach wysoce uprzywilejowanego źródła. Złośliwy lub wadliwy widżet mógłby odczytywać dane, wywoływać działania albo przechwytywać informacje o sesji. Jeśli natywne widżety zostaną wprowadzone, bezpieczniejszy projekt będzie wymagał piaskownicy, zakresów uprawnień i kontrolowanego API widżetów.
Ryzyko skryptów międzywitrynowych opisane przez OWASP wyjaśnia podstawowy problem bezpieczeństwa przeglądarki.
Do monitorowania preferuj widżety tylko do odczytu
Zużycie procesora, pojemność pamięci masowej, temperatury, czas działania i stan usług łatwiej bezpiecznie udostępniać niż działania zmieniające stan systemu. Przycisk „wyłącz Pi-hole” lub „uruchom ponownie kontener” wymaga silniejszego uwierzytelniania, rejestrowania działań i potwierdzenia, ponieważ kliknięcie na pulpicie może zmienić stan infrastruktury.
Odpytywanie wykonuj wydajnie, zamiast robić to co kilka sekund
Częste odpytywanie generuje stały ruch w tle na serwerze o niskim poborze mocy. W przypadku pamięci masowej, temperatur i stanu usług często wystarczy 30–60 sekund. Pogoda może wymagać aktualizacji tylko co kilka minut. W miarę możliwości używaj aktualizacji sterowanych zdarzeniami zamiast odpytywać wszystko w tym samym interwale.
Przechowuj sekrety po stronie serwera
Jeśli widżet potrzebuje tokenu API do pogody, Pi-hole, AI lub innej usługi, nie umieszczaj go w kodzie JavaScript wykonywanym w przeglądarce. Użyj serwera proxy lub integracji po stronie serwera, która przechowuje dane uwierzytelniające poza pakietem klienta. Obsługa HTTPS i proxy w ZimaOS jest przydatna, gdy usługi muszą być dostępne z poziomu przeglądarki.
Jeśli chcesz maksymalnej swobody, użyj osobnego pulpitu
Samodzielny kontener pulpitu zapewnia pełną kontrolę nad układem i integracjami bez modyfikowania samego ZimaOS. Dzięki temu lepiej znosi także przebudowy frontendu ZimaOS. W przypadku uprzywilejowanych zadań odsyłaj do natywnego pulpitu administracyjnego zamiast kopiować wszystkie elementy sterujące systemem do niestandardowej warstwy.
Czego potrzebowałby bezpieczny natywny system widżetów
Dobra implementacja powinna definiować manifesty widżetów, żądane uprawnienia, izolowane renderowanie, limity żądań, zgodność wersji, sekrety przechowywane po stronie serwera oraz wyraźne rozróżnienie między widżetami tylko do odczytu a widżetami modyfikującymi stan. Najważniejszym elementem pierwotnej prośby jest potrzeba stworzenia pełnoprawnego interfejsu rozszerzeń, a nie umożliwienia wykonywania nieograniczonego kodu.
Wersjonuj niestandardowy pulpit niezależnie od ZimaOS
Przechowuj kod widżetów, adaptery API i konfigurację w systemie kontroli wersji. Gdy ZimaOS zmieni wersję API lub sposób uwierzytelniania, możesz świadomie zaktualizować integrację zamiast utracić ręcznie edytowany skrypt wewnątrz kontenera. Niewielka warstwa zgodności pozwala także temu samemu pulpitowi komunikować się z wieloma urządzeniami ZimaOS bez powielania kodu.
Najczęściej zadawane pytania
Czy mogę dodawać niestandardowe widżety bezpośrednio do ZimaOS?
Obecnie dostępne publicznie materiały nie dokumentują dowolnych widżetów HTML/JavaScript definiowanych przez użytkownika jako wbudowanej funkcji.
Czy mogę zbudować pulpit ZimaOS za pomocą OpenAPI?
Tak. Zewnętrzne pulpity mogą korzystać z obsługiwanych interfejsów API ZimaOS i renderować własne widżety.
Czy widżety powinny przechowywać klucze API w JavaScript?
Nie. Dane uwierzytelniające usług przechowuj po stronie serwera.
Czy Homarr jest dobrą alternatywą?
Tak, jeśli celem jest konfigurowalny pulpit, a nie modyfikowanie natywnego interfejsu ZimaOS.
Dlaczego nie zezwalać na dowolny JavaScript?
Pulpit jest uwierzytelnionym interfejsem administracyjnym, więc nieograniczone skrypty stwarzałyby poważne zagrożenia związane z XSS i uprawnieniami.
