Wydruk przerwano o 3:40, nikt się nie przyznaje. Czy panel zapisał, kto to zrobił, zależy od pola user

Wydruk z nocnej zmiany ma w historii status „anulowany” i godzinę 3:40. Rano przy maszynach stoją trzy osoby i żadna nie przypisuje sobie tej decyzji. W rekordzie tego zadania jest jedno pole na nazwę użytkownika — i zależnie od tego, czym ta hala jest obsługiwana, znajdziesz w nim nazwę osoby, która wydruk zleciła, albo nie znajdziesz nikogo.

Różnica nie bierze się z ustawienia, które ktoś przeoczył. Bierze się z tego, że zlecenie zadania i jego przerwanie to w strukturze zapisu dwa osobne pola, a nie każde oprogramowanie prowadzi oba.

Kto zlecił i kto przerwał to dwa różne pola

Najłatwiej to zobaczyć na zdarzeniach OctoPrinta. W dokumentacji zdarzeń zdarzenie PrintCancelled ma w ładunku dwa osobne pola osobowe: owner, opisane jako „the user who started the print job (if available)”, oraz user — „the user who cancelled the print job (if available)”. To są dwie różne osoby i system je rozdziela.

Ta sama dokumentacja pokazuje, że rozdzielenie nie obowiązuje wszędzie. PrintStarted ma oba pola, bo zlecający i wykonujący akcję to w tym momencie ta sama osoba. Natomiast PrintDone i PrintFailed mają już tylko owner — nie ma tam pola user, bo nikt tych zdarzeń nie wywołał ręcznie. Wniosek praktyczny: wydruk, który padł sam, nie ma w zapisie żadnej osoby poza tą, która go wypuścił. Wydruk, który ktoś zatrzymał, ma dwie.

Jeśli Twój spór dotyczy wydruku przerwanego, a nie nieudanego, to szukasz pola user, nie owner. W większości interfejsów historia pokazuje domyślnie jedno z nich i prawie zawsze jest to to drugie.

Moonraker zapisuje zlecającego, przerywającego nie zapisuje wcale

Na maszynach z Klipperem rolę rejestru zdarzeń pełni moduł historii Moonrakera. Lista pól przechowywanych dla każdego zadania w dokumentacji API historii wygląda tak: job_id, user, filename, exists, status, start_time, end_time, print_duration, total_duration, filament_used, metadata, auxiliary_data.

Jedno pole osobowe, user, i specyfikacja opisuje je jednoznacznie jako „The user that started the job”. Pola z osobą, która zadanie anulowała, na tej liście nie ma. Status cancelled jest w tej samej dokumentacji opisany jako „The job was cancelled by the user” — zdanie, które stwierdza, że to był człowiek, i nie podaje który.

Drugi szczegół z tej samej specyfikacji: pole user jest null, kiedy Moonraker nie potrafi ustalić użytkownika — na przykład dla zadań uruchomionych z wyświetlacza przy maszynie. Zadanie wystartowane ręcznie z ekranu nie ma w historii nikogo. Dla hali, w której połowa wydruków startuje z panelu na maszynie, to oznacza, że połowa rekordów jest pod tym względem pusta i nie jest to usterka do naprawienia ustawieniem.

Jeden wpis w trusted_clients zdejmuje pytanie o tożsamość

Zanim w ogóle dojdzie do zapisu, musi być co zapisać. W Moonrakerze decyduje o tym sekcja [authorization], obowiązkowa w pliku konfiguracyjnym. Według dokumentacji konfiguracji opcja trusted_clients przyjmuje adresy i zakresy w notacji CIDR, a klienci z tej listy mają — cytując — „full access to the API”. Domyślnie nie jest zaufany nikt: „The default is no IPs or domains are trusted.”

Problem pojawia się przy typowym skrócie instalacyjnym, czyli wpisaniu całej podsieci warsztatu. Od tego momentu każde urządzenie w tej sieci ma pełny dostęp do API bez logowania i bez klucza, a więc i bez tożsamości, którą dałoby się wpisać do rekordu. Telefon, który przez przeglądarkę zatrzyma wydruk, zostawi w historii dokładnie tyle samo śladu co komputer w biurze.

Przeciwwagą jest opcja force_logins, domyślnie ustawiona na False. Ta sama dokumentacja opisuje ją tak, że po utworzeniu choćby jednego użytkownika logowanie staje się wymagane, a ustawienie to jest nadrzędne wobec listy trusted_clients. To jedyny przełącznik w tej sekcji, który zamienia wygodę w możliwość ustalenia sprawcy.

Klucz API to jedna tożsamość dla wszystkich, którzy go mają

Dokumentacja autoryzacji Moonrakera rozdziela dwie drogi dla klientów niezaufanych: token JWT w nagłówku Authorization jako typ Bearer albo klucz API w nagłówku X-Api-Key. Token dostępowy wygasa po godzinie, co jest zapisane wprost: „This token expires after 1 hour.”

Dla trzeciej drogi, czyli połączeń, które nie mogą ustawić nagłówka — na przykład WebSocket — przewidziano tokeny jednorazowe przekazywane w zapytaniu. Ich parametry też są podane: „Tokens expire in 5 seconds and may only be used once”. Pięć sekund i jedno użycie to projekt, który zakłada, że token nie będzie krążyć.

Klucz API jest przeciwieństwem tego podejścia. Dokumentacja mówi o nim w liczbie pojedynczej i wspomina o „api key user” jako o osobnej tożsamości. Jeśli ten jeden klucz jest wklejony w skrypcie, we wtyczce i w zakładce przeglądarki u dwóch osób, to w logu każde z tych wywołań wygląda identycznie. Klucz nie jest kontem na osobę i nie zamienia się w nazwisko.

Trzy osoby na jednym loginie dają jedną linię w zapisie

Po stronie OctoPrinta kontrola dostępu nie jest opcjonalna — dokumentacja podaje, że od wersji 1.5.0 jest wymuszona. Predefiniowane grupy to Admins z pełnym dostępem administracyjnym, Operator jako grupa domyślna dla nowych kont i obsługująca normalną pracę z maszyną, Guests ustawiająca prawa dla niezalogowanych oraz Read-only Access, która startuje bez użytkowników i daje podgląd stanu, plików bez wysyłania, temperatur, kamery, podglądu G-code’u i wyjścia terminala bez możliwości wysyłania komend.

Ta ostatnia grupa jest tu najciekawsza praktycznie. Jeżeli ktoś ma tylko patrzeć, czy wydruk idzie, to nie potrzebuje konta, które potrafi anulować zadanie. Rozdzielenie podglądu od sterowania jest w OctoPrincie gotowe i nie wymaga wtyczki.

U Prusy odpowiednikiem są zespoły w Connect. Opis producenta mówi o zarządzaniu rolami członków zespołu i podaje przykład klasy szkolnej ograniczonej do sprawdzania stanu drukarki bez możliwości jej sterowania, a regulamin usługi dodaje, że każdy użytkownik jest administratorem własnej grupy i nadaje prawa członkom. Pełnej tabeli uprawnień per rola Prusa publicznie nie udostępnia, więc zakres każdej roli trzeba sprawdzić w swoim panelu, zanim oprzesz na nim podział obowiązków. Tak samo dla panelu Bambu: publicznej dokumentacji ról i struktury zapisu zdarzeń nie ma, a opisy krążące po serwisach trzecich nie są źródłem, na którym można oprzeć procedurę.

Czego nie obejmie żaden z tych logów

Trzy luki są wpisane w konstrukcję, nie w konfigurację, i warto je znać zawczasu.

• Kamera stoi poza kontrolą dostępu. Dokumentacja OctoPrinta stwierdza to bez ogródek: „OctoPrint does not control the webcam and merely embeds it, and thus also cannot limit access to it.” Konto bez prawa podglądu nie oznacza, że obraz jest niedostępny — adres strumienia wystarczy.
• Autologowanie świadomie znosi uwierzytelnienie. Ta sama strona opisuje je jako mechanizm, który „can be used to bypass authentication for hosts on the network(s) that you trust”. Włączone w warsztacie z jednym wspólnym komputerem daje jedną nazwę użytkownika dla wszystkich, którzy do tego komputera siadają.
• Ekran przy maszynie nie zna kont. Dotknięcie „stop” na wyświetlaczu nie przechodzi przez żaden panel. W historii Moonrakera takie zadanie ma user równe null, a w praktyce każdego innego systemu jest to akcja bez autora.

Pierwsze dwie luki zamykasz ustawieniem. Trzeciej nie zamkniesz w oprogramowaniu — to kwestia tego, kto fizycznie podchodzi do maszyny, i rozstrzyga się organizacyjnie albo wcale.

Lista kontrolna, zanim wróci pytanie o godzinę 3:40

Reguła nadrzędna wobec całej listy: sprawdzaj to, co jest w zapisie, nie to, co pokazuje interfejs. Panel potrafi wyświetlić akcję, dla której w strukturze danych nie ma gdzie zanotować autora — tak samo jak formularz, który nie dopuszcza ujemnej liczby sztuk, choć w bazie taka wartość już leży. Oba przypadki rozstrzyga ta sama czynność: zajrzenie do rekordu.

Do wydrukowania i odhaczenia przy każdym stanowisku:

• Sprawdź w historii jednego zakończonego i jednego anulowanego zadania, które pola osobowe faktycznie są wypełnione. To pomiar, nie lektura dokumentacji.
• Ustal, czy w trusted_clients jest wpisana cała podsieć. Jeśli tak, policz, ile urządzeń w niej jest.
• Włącz force_logins i utwórz konto na osobę, a nie na stanowisko.
• Policz, ile kopii klucza API krąży: skrypty, wtyczki, zakładki w przeglądarkach, zapisane kolekcje zapytań.
• Przenieś osoby, które mają tylko patrzeć, do grupy podglądowej — w OctoPrincie to Read-only Access.
• Wyłącz autologowanie na komputerach używanych przez więcej niż jedną osobę.
• Zapisz, ile zadań startuje z wyświetlacza przy maszynie. To udział wydruków, dla których pole użytkownika zostanie puste.
• Ustal jedną ścieżkę zatrzymywania wydruków i wpisz ją do procedury — panel, nie ekran.

Decyzja, którą trzeba podjąć raz

Pytanie nie brzmi „jak poprawić logi”, bo pola, którego nie ma w specyfikacji, nie dopiszesz. Brzmi: czy przerwanie wydruku ma być w tej hali akcją wymagającą tożsamości.

Jeśli tak, wynika z tego konkretna konfiguracja: konto na osobę, force_logins włączone, podsieć wyjęta z listy zaufanych, jedna droga zatrzymywania wydruku przez panel. Kosztem jest logowanie przy każdym podejściu do maszyny i to jest realny koszt przy kilkudziesięciu interakcjach dziennie.

Jeśli nie — zostaw konfigurację, jaka jest, ale przestań traktować historię zadań jako dowód w sprawie, kto co zrobił. Pole user przy anulowanym zadaniu w Moonrakerze nie istnieje i nie pojawi się tylko dlatego, że ktoś go w sporze potrzebuje. Najgorszy wariant to trzeci: wspólne konto, zaufana podsieć i przekonanie, że system „to gdzieś zapisuje”.