Gdy host WOPI zgłasza „niepowodzenie weryfikacji dowodu” lub „Nieprawidłowy dowód WOPI”, najpierw sprawdź, który system zarejestrował odrzucenie. Jeśli host pamięci masowej odrzuca podpisane żądanie Collabora, sprawdź parę kluczy dowodu i odpowiedź wykrywania przed zmianą listy dozwolonych hosta WOPI lub wyłączeniem sprawdzania dowodów. W przypadku instalacji pakietów Collabora zazwyczaj generuje parę kluczy; w przypadku wdrożeń Docker, Kubernetes i wdrożeń z wieloma replikami, para musi być dostarczona i spójnie utrwalona.
Walidacja dowodu WOPI wykorzystuje podpisane żądanie i klucz publiczny reklamowany przez klienta WOPI w jego metadanych wykrywania. Jest ona niezależna od listy zaufanych hostów WOPI Collabora, walidacji certyfikatu TLS i sprawdzania tokena dostępu hosta pamięci masowej. Regeneracja klucza może pomóc w przypadku braku klucza prywatnego lub niezgodności z reklamowanym kluczem publicznym, ale może również spowodować nową niezgodność, jeśli zmieni się tylko jedna replika lub host nadal ma buforowane dane wykrywania.
| Dowody w dzienniku | Prawdopodobny obszar do sprawdzenia |
|---|---|
| Host pamięci masowej wyświetla komunikat „Nieprawidłowy dowód WOPI” podczas odbierania CheckFileInfo lub innego żądania WOPI | Klucz dowodowy Collabora, dane odkrywcze hosta, rekonstrukcja adresu URL lub znacznik czasu |
| Collabora wyświetla komunikat „Nieautoryzowany host WOPI” lub „Brak akceptowalnych hostów WOPI” | Konfiguracja listy dozwolonych hostów WOPI/domeny, a nie klucz dowodowy |
| Token jest nieprawidłowy, wygasł lub dostęp jest zabroniony bez błędu dowodowego | Token dostępu wydany przez hosta, uprawnienia lub wygaśnięcie tokena |
Sprawdź jedno nieudane żądanie w dziennikach Collabora i hosta magazynu; sam wskaźnik przeglądarki nie identyfikuje błędu klucza dowodowego.
Zacznij od opcji najmniej uciążliwej. W przypadku instalacji opartej na pakietach, najpierw zweryfikuj istniejące pliki kluczy i logi usług; aktualna dokumentacja Collabora podaje, że instalacje pakietów RPM i Debian automatycznie generują parę kluczy WOPI proof. Jeśli te pliki są obecne i stabilne, ich rotacja zazwyczaj nie jest konieczna.
| Wdrożenie | Zalecane działanie | Kompromis |
|---|---|---|
| Pojedynczy serwer zarządzany pakietami | Zachowaj wygenerowaną parę kluczy; napraw uprawnienia lub wygeneruj ponownie tylko w przypadku ich braku lub niezgodności | Minimalna zmiana, ale sprawdź wersję pakietu i skonfigurowane ścieżki |
| Pojedynczy kontener Docker | Wygeneruj parę raz i zamontuj ją trwale w kontenerze | Wymaga trwałego woluminu i prawidłowego dostępu do odczytu dla coolwsd |
| Kubernetes lub wiele replik | Zamontuj jedną współdzieloną parę kluczy tajnych/kluczy w każdej instancji Collabora | Spójne podpisy we wszystkich replikach; rotacja musi również aktualizować widok wykrywania hosta |
| Zmieniono adres URL hosta za serwerem proxy | Sprawdź schemat publiczny, hosta, ścieżkę i ciąg zapytania używany do walidacji podpisu | Bardziej skomplikowane niż rotacja kluczy, ale pozwala uniknąć niepotrzebnych zmian danych uwierzytelniających |
W podręczniku Collabora 24.04 napisano, że publiczny obraz Dockera nie zawiera pary kluczy dowodowych; należy ją wygenerować i trwale zamontować. Oficjalny diagram Helm obsługuje klucze dowodowe Secrets. Nigdy nie generuj osobnej pary dla każdej repliki, ponieważ równoważenie obciążenia może powodować sporadyczne awarie.
coolwsd.xmlścieżki klucza dowodowego i upewnij się, że zarówno klucz prywatny, jak i klucz publiczny są dostępne. Typowe lokalizacje znajdują się poniżej /etc/coolwsd/, ale układy pakietów i kontenerów mogą się różnić. Nigdy nie wklejaj klucza prywatnego do logów, zgłoszeń ani czatu.sudo openssl pkey -in /etc/coolwsd/proof_key -pubout -outform DER | sha256sumi openssl pkey -pubin -in /etc/coolwsd/proof_key.pub -outform DER | sha256sum. Uzyskane skróty powinny być zgodne. Jeśli ścieżki się różnią, zastąp je ścieżkami skonfigurowanymi w rzeczywistości. Jeśli nie można odczytać klucza prywatnego, popraw jego właściciela i uprawnienia zgodnie z modelem bezpieczeństwa usługi; nie ustawiaj go jako powszechnie czytelnego.sudo coolconfig generate-proof-keytego narzędzia w miejscu, w którym jest zainstalowane. W przypadku platformy Docker wygeneruj parę w odpowiedniej, trwałej lokalizacji, a następnie zamontuj oba pliki w miejscu, w którym Collabora ich oczekuje, i upewnij się, że proces coolwsd może odczytać klucz prywatny. Na platformie zarządzanej użyj obsługiwanego mechanizmu Secret zamiast ręcznie edytować działający pod.
Sprawdź synchronizację czasu w obu systemach. Żądania WOPI zawierają znacznik czasu; host może odrzucić stary znacznik czasu lub znacznik czasu nieaktualny. Upewnij się, że protokół NTP lub usługa czasu platformy działają prawidłowo i że serwery zgłaszają sensowne czasy UTC. Nie pomijaj kontroli znacznika czasu, aby obejść problem z zegarem.
Następnie sprawdź publiczny adres URL używany przez hosta do rekonstrukcji podpisanego żądania. Dowód jest powiązany z adresem URL żądania, w tym z odpowiednimi parametrami zapytania, a specyfikacja WOPI wymaga, aby reprezentacja adresu URL używana do walidacji była zgodna z podpisanym formularzem. Odwrotny serwer proxy, który kończy protokół HTTPS, może spowodować, że aplikacja zobaczy wewnętrzny adres URL HTTP, mimo że Collabora podpisała publiczny adres URL HTTPS. Skonfiguruj zaufane nagłówki serwera proxy i ustawienia zewnętrznego adresu URL aplikacji zgodnie z oficjalnymi wytycznymi hosta WOPI; nie przepisuj logiki dowodu ani nie usuwaj parametrów zapytania.
Jeśli dowód nie zadziała dopiero po rotacji klucza, odśwież proces wykrywania i sprawdź, czy wszystkie repliki Collabora ujawniają ten sam klucz publiczny. Jeśli nie powiodą się tylko żądania kierowane przez jeden serwer proxy lub jedną replikę, porównaj logi i konfigurację tej ścieżki, zamiast ponownie rotować klucz. Wyłączenie walidacji dowodu może osłabić kontrolę bezpieczeństwa i nie powinno być stosowane jako rozwiązanie w środowisku produkcyjnym.
Pomyślne otwarcie dokumentu weryfikuje tylko tę ścieżkę; powtórz sprawdzanie dla każdego hosta WOPI i trasy proxy, którą obsługujesz.
Śledź błędy dowodowe Collabora WOPI w przypadku niedopasowanych kluczy, nieaktualnych danych wykrywania, przesunięcia zegara lub zmian adresu URL serwera proxy — bez osłabiania walidacji.
Zresetuj powiększenie przeglądarki, przetestuj czystą sesję i zidentyfikuj, kiedy nieprawidłowo sformatowane menu rozmiarów wymaga aktualizacji serwera Collabora.
Wdróż Collabora CODE z Dockerem, połącz go bezpiecznie z Nextcloud Office i weryfikuj edycję dokumentów za pomocą praktycznych kontroli WOPI i serwerów proxy.
Tymczasowo uruchom coolwsd w celu debugowania, przechwyć jedno nieudane otwarcie i użyj sekwencji dziennika do oddzielenia problemów z WebSocket, WOPI, serwerem proxy i kontenerem.
Skonfiguruj logowanie administratora Collabora Online dla Dockera lub Linuxa, uruchom ponownie odpowiednią usługę i zweryfikuj nowe hasło, nie ujawniając go.
Przed zmianą ustawień Collabora lub ponownym uruchomieniem usługi sprawdź, czy obciążenie procesora pochodzi od aktywnych dokumentów, bezczynnych procesów roboczych czy przepustowości serwera.
Sprawdź, czy Docker ogranicza KOD Collabora, bezpiecznie podnieś limit pamięci Compose i potwierdź, że działający kontener otrzymał nowy limit.
Uprość środowisko Collabora CODE dzięki trybowi kompaktowemu lub z zakładkami oraz kontrolkom WOPI PostMessage, aby bezpiecznie ukryć wybrane przyciski, polecenia i zakładki.
Przypisz Nginxowi obsługę protokołu HTTPS dla kontenera Collabora CODE, popraw edycję WebSockets i zweryfikuj publiczny punkt końcowy bez ujawniania portu 9980.
Rozwiąż problem z klawiaturą przeglądarki mobilnej zasłaniającą tekst w usłudze Collabora Online, korzystając z szybkich obejść i oddzielnych sprawdzeń dla przeglądarek, osadzonych elementów WebViews i stron hosta.
