Trzy odmowy, które
wyglądają tak samo

Jeden przebieg, jedno konto, trzy różne kody

Pytasz kontroler UniFi o dziennik zdarzeń i dostajesz odmowę. Próbujesz pod innym adresem — znowu odmowa. Po trzeciej próbie nasuwa się wniosek: nie ma takiego API. To najczęstsza pomyłka w tym miejscu — i my też ją popełniliśmy.

Sprawdziliśmy to inaczej. Zapytaliśmy o dziennik zdarzeń pod pięcioma adresami naraz, jednym przebiegiem i tym samym kontem lokalnym tylko do odczytu. Kontroler odpowiedział trzema różnymi kodami.

Człon default w adresie to nazwa witryny. W naszej instalacji witryna jest jedna i tak się nazywa. U Ciebie nazwa bywa inna, więc podstaw swoją.

Gdyby te adresy sprawdzać po kolei, w różnych dniach i różnymi narzędziami, każda odpowiedź wyglądałaby tak samo — na „nie da się". Dopiero zestawienie pokazuje, że za każdym razem blokuje co innego.

Wszystkie kody w tym artykule pochodzą z pomiaru 6 września 2026, godz. 09:52–09:55, na działającej instalacji: brama UDM-Pro z UniFi OS 5.1.31 i UniFi Network 10.6.101. Robiliśmy wyłącznie odczyty, jednym kontem lokalnym tylko do odczytu.

Co znaczy każdy z trzech kodów

Trzy kody to trzy różne przyczyny i trzy różne reakcje. Pomylenie ich kosztuje godziny szukania w złym miejscu.

403 — adres istnieje, Twoje konto nie ma prawa

Kontroler zna tę ścieżkę i rozumie zapytanie. Odmawia, bo konto nie ma uprawnienia do dziennika zdarzeń. Żeton jest przy tym ważny: to samo konto w tej samej chwili czyta stan urządzeń i dostaje 200.

Reakcja: zmień rolę konta. Szukanie innego adresu nie pomoże, bo adres jest dobry.

404 — tej ścieżki nie ma w tym wydaniu

Ścieżki stat/event i stat/alarm to stare adresy dziennika zdarzeń. Krążą w opisach sprzed lat i dziś zwracają właśnie 404. W wydaniu, które zmierzyliśmy, nie ma ich wcale.

Reakcja: szukaj nowej ścieżki, nie zmieniaj konta. W naszym pomiarze dziennik odpowiada pod adresami /v2/api/… — kodem 403, czyli istnieje.

Nie wiemy, w którym wydaniu stare adresy zniknęły. Mamy jeden kontroler i jedno wydanie, więc porównania nie zrobiliśmy.

400 — adres istnieje, zapytanie jest źle zbudowane

To najbardziej mylący kod z trzech, bo wygląda na awarię. Kontroler znalazł ścieżkę i wziął ją do obsługi. Odrzucił treść zapytania: brakujący parametr, złą metodę albo zły zakres czasu.

Reakcja: popraw zapytanie. Adres i konto zostaw w spokoju.

Konto tylko do odczytu widzi dziennik — wbrew temu, co tu pisaliśmy

Przez dwa tygodnie stało w tym miejscu zdanie odwrotne: że konto tylko do odczytu dostaje na dzienniku 403. Pomiar z 7 września 2026 to obalił. Konto o najniższych prawach czyta dziennik aktywności administratorów dokładnie tak samo jak administrator.

Pomyliliśmy się nie w rozumowaniu, tylko w adresie. Pytaliśmy bez przedrostka /proxy/network, czyli warstwy systemu, która o tym API nic nie wie. Pod właściwym adresem, metodą POST, oba konta dostają dane. Pełne zestawienie jest na końcu.

Co z tego wynika dla konta u klienta

Wniosek odwraca się o sto osiemdziesiąt stopni i staje się ostrzeżeniem, a nie ograniczeniem.

Dziennik aktywności administratorów zawiera nazwę konta, czas logowania i adres publiczny osoby, która się logowała. Zakładając klientowi konto „tylko do odczytu" do monitoringu, zakładasz konto, które to widzi. Nazwa roli sugeruje coś węższego, niż rola naprawdę daje.

„Tylko do odczytu" mówi o zapisie, nie o zakresie. Takie konto nie zmieni ustawień, ale zobaczy, kto i skąd logował się do kontrolera. Jeśli klient ma z tym problem, trzeba to ustalić przed założeniem konta — nie po.

Czego nie sprawdziliśmy: czy w kontrolerze da się zawęzić rolę tak, żeby czytała stan urządzeń, a dziennika już nie. Zmierzyliśmy dwie role, obie widzą jedno i drugie.

Jak rozstrzygnąć, czy adres w ogóle istnieje

Jeden adres i jeden kod nie mówią nic. Odpowiedź daje dopiero zestawienie kilku adresów, sprawdzonych naraz tym samym kontem.

1. Zaloguj się raz i zachowaj żeton z ciasteczka. Wszystkie próby mają iść tym samym kontem, bo inaczej porównujesz konta, a nie adresy.
2. Zbierz adresy na listę — kilka wariantów tej samej funkcji, razem z tymi starymi, z opisów sprzed lat.
3. Dołóż adres kontrolny, o którym wiesz, że działa. U nas jest to zapytanie o stan urządzeń.
4. Wyślij wszystko jednym przebiegiem. W jednej chwili i jednym narzędziem.
5. Zapisz sam kod przy każdym adresie. Zrób to, zanim zajrzysz w treść odpowiedzi.
6. Porównaj kody ze sobą, a nie każdy z osobna.

Adres kontrolny jest ważniejszy, niż wygląda. Bez niego seria samych odmów wygląda tak samo jak martwy żeton. Kod 200 na adresie kontrolnym mówi, że konto żyje, a odmowa dotyczy tylko dziennika.

Po czym poznasz, że wyszło

Masz listę, w której przy każdym adresie stoi liczba, a nie komunikat narzędzia. Adres kontrolny odpowiedział 200. Wśród pozostałych stoją co najmniej dwa różne kody — i to jest cały wynik. Różnica między nimi pokazuje, czy blokuje konto, ścieżka, czy treść zapytania.

Ten sam kod pod wszystkimi adresami też jest wynikiem, tylko węższym: przyczyna jest jedna i już wiesz która. Adres kontrolny inny niż 200 unieważnia cały przebieg — wtedy mierzysz swoje narzędzie, a nie kontroler.

Czego nie zmierzyliśmy

Ten artykuł opisuje jeden kontroler, jedno wydanie i jedno konto. Trzy rzeczy zostają otwarte i piszemy to wprost, zamiast zgadywać.

• Czy stare adresy żyją na starszych wydaniach. Mamy jedno wydanie, więc 404 mówi o nim, a nie o UniFi w ogóle.
• Jak zbudować zapytanie, które adres z kodem 400 przyjmie. Zmierzyliśmy samą odmowę, bez szukania poprawnej postaci.

Konto lokalne, żeton i to, co kontroler oddaje w jednej odpowiedzi, opisujemy osobno w artykule o czytaniu całej floty jednym zapytaniem.

Poprawka: myliliśmy się, i to w rzeczy najważniejszej

7 września 2026 powtórzyliśmy pomiar dwoma kontami o znanych rolach — administratora i tylko do odczytu. Dziennik zdarzeń czytają oba, tak samo. Wcześniejszy wniosek, że konto tylko do odczytu dostaje odmowę, był nieprawdziwy.

Co dokładnie zmierzyliśmy

Pytaliśmy pod adresem /proxy/network/v2/api/site/<witryna>/system-log/<kategoria>, metodą POST. Oba konta, ten sam kontroler, ten sam przebieg.

W obu przebiegach sprawdziliśmy też, że konto w ogóle czyta cokolwiek: zapytanie o listę urządzeń oddało trzy sztuki. Bez tego sprawdzenia odmowa na dzienniku nie odróżniałaby braku uprawnień od zerwanej sesji.

Trzy wnioski, każdy praktyczny

1. Konto „tylko do odczytu" widzi, kto się logował. Dziennik aktywności administratorów zawiera nazwę konta, czas i adres publiczny osoby logującej się. Zakładając klientowi konto do monitoringu, zakładasz też konto, które to widzi. Warto o tym powiedzieć, zanim ktoś odkryje to sam.
2. Odmowa należała do adresu, nie do roli. Skoro konto o najniższych prawach dostaje dane pod właściwym adresem, wcześniejsze 403 nie mogło pochodzić od uprawnień aplikacji sieciowej. Pytaliśmy warstwy systemu, która o tym API nic nie wie.
3. Brakujących kategorii nie ma, i to nie z powodu uprawnień. Administrator dostaje na nie ten sam 404 co konto do odczytu.

Zostawiamy poprzednią wersję tego artykułu widoczną w tej poprawce, zamiast po cichu ją nadpisać. Zdanie „sprawdziliśmy i wyszło inaczej" jest warte więcej niż tekst, który zawsze miał rację.