Când o gazdă WOPI raportează „validarea probei a eșuat” sau „Probă WOPI invalidă”, confirmați mai întâi care sistem a înregistrat respingerea. Dacă gazda de stocare respinge solicitarea semnată de Collabora, verificați perechea cheie-probă și răspunsul de descoperire înainte de a modifica listele de permisiuni ale gazdei WOPI sau de a dezactiva verificările probei. Pentru instalările de pachete, Collabora generează în mod normal perechea de chei; pentru implementările Docker, Kubernetes și multi-replică, perechea trebuie furnizată și persistată în mod consecvent.
Validarea dovezii WOPI utilizează o cerere semnată și cheia publică anunțată de clientul WOPI în metadatele sale de descoperire. Este separată de lista de gazde WOPI de încredere a Collabora, validarea certificatului TLS și verificarea token-ului de acces al gazdei de stocare. O regenerare a cheii poate fi utilă atunci când cheia privată lipsește sau nu se potrivește cu cheia publică anunțată, dar poate crea o nouă nepotrivire dacă se modifică o singură replică sau o gazdă are încă date de descoperire stocate în cache.
| Dovezi în jurnal | Zona probabilă de verificat |
|---|---|
| Gazda de stocare afișează „Dovadă WOPI nevalidă” în timp ce primește CheckFileInfo sau o altă solicitare WOPI | Cheia de verificare a Collabora, datele de descoperire ale gazdei, reconstrucția URL-ului sau marcajul temporal |
| Collabora afișează mesajul „Gazdă WOPI neautorizată” sau „Nu există gazde WOPI acceptabile” | Configurația domeniului/lista de acces permisă a gazdei WOPI, nu cheia de probă |
| Token invalid, expirat sau acces refuzat fără o eroare de probă | Token de acces emis de gazdă, permisiuni sau expirarea tokenului |
Verificați o solicitare eșuată atât în jurnalul Collabora, cât și în jurnalul gazdei de stocare; o funcție de rotire a browserului singură nu identifică o eroare a cheii de probă.
Începeți cu opțiunea cea mai puțin perturbatoare. La o instalare bazată pe pachete, verificați mai întâi fișierele cheie și jurnalele de service existente; documentația actuală Collabora spune că instalările de pachete RPM și Debian generează automat o pereche de chei de probă WOPI. Dacă aceste fișiere sunt prezente și stabile, rotirea lor este de obicei inutilă.
| Implementare | Acțiune recomandată | Compromis |
|---|---|---|
| Server gestionat cu un singur pachet | Păstrați perechea de chei generată; reparați permisiunile sau regenerați-le numai dacă lipsesc sau nu corespund. | Schimbare minimă, dar verificați versiunea pachetului și căile configurate |
| Container Docker unic | Generează o pereche o dată și montează-o persistent în container | Necesită un volum persistent și acces corect de citire pentru coolwsd |
| Kubernetes sau replici multiple | Montați o pereche secret/cheie partajată în fiecare instanță Collabora | Semnături consecvente între replici; rotația trebuie să actualizeze și vizualizarea de descoperire a gazdei |
| Adresa URL a gazdei a fost modificată în spatele unui proxy | Verificați schema publică, gazda, calea și șirul de interogare utilizate pentru validarea semnăturii | Mai complex decât rotirea cheilor, dar evită modificările inutile ale acreditărilor |
Manualul Collabora 24.04 spune că imaginea publică Docker nu include o pereche cheie-proof; generați una și montați-o persistent. Diagrama oficială Helm acceptă Secrete cheie-proof. Nu generați niciodată o pereche separată pentru fiecare replică, altfel echilibrarea încărcării poate face ca eșecurile să fie intermitente.
coolwsd.xmlpentru calea cheii de probă și verificați dacă atât cheia privată, cât și cheia publică sunt disponibile. Locațiile comune se află sub /etc/coolwsd/, dar aspectele pachetului și ale containerului pot diferi. Nu lipiți niciodată cheia privată în jurnale, tichete sau chat.sudo openssl pkey -in /etc/coolwsd/proof_key -pubout -outform DER | sha256sumși openssl pkey -pubin -in /etc/coolwsd/proof_key.pub -outform DER | sha256sum. Valorile hash rezultate ar trebui să se potrivească. Dacă căile dvs. diferă, înlocuiți-le cu căile configurate efectiv. Dacă cheia privată nu poate fi citită, corectați proprietatea și permisiunile acesteia în funcție de modelul de securitate al serviciului; nu o faceți lizibilă de către întreaga lume.sudo coolconfig generate-proof-keylocul unde este instalat utilitarul respectiv. Pentru Docker, generați perechea într-o locație persistentă adecvată, apoi montați ambele fișiere acolo unde Collabora le așteaptă și asigurați-vă că procesul coolwsd poate citi cheia privată. Pe o platformă gestionată, utilizați mecanismul Secret acceptat în loc să editați manual un pod care rulează.
Verificați sincronizarea timpului pe ambele sisteme. Cererile de verificare WOPI includ o marcă temporală; o gazdă poate respinge o marcă temporală veche sau în afara ferestrei. Confirmați că NTP sau serviciul de timp al platformei este funcțional și că serverele raportează ore UTC rezonabile. Nu slăbiți verificările marcălor temporale pentru a rezolva o problemă de sincronizare non-stop.
Apoi, inspectați adresa URL publică pe care gazda o folosește pentru a reconstrui cererea semnată. Dovada este legată de adresa URL a cererii, inclusiv parametrii de interogare relevanți, iar specificația WOPI impune ca reprezentarea URL utilizată pentru validare să corespundă cu formularul semnat. Un proxy invers care termină HTTPS poate face ca aplicația să vadă o adresă URL HTTP internă, chiar dacă Collabora a semnat adresa URL HTTPS publică. Configurați anteturile proxy de încredere și setările URL externe ale aplicației conform instrucțiunilor oficiale ale gazdei WOPI; nu rescrieți logica de demonstrare și nu eliminați parametrii de interogare.
Dacă validarea eșuează doar după o rotație a cheii, reîmprospătați descoperirea și verificați dacă toate replicile Collabora expun aceeași cheie publică. Dacă eșuează doar solicitările rutate printr-un proxy sau o replică, comparați jurnalele și configurația acelei căi, în loc să rotiți din nou cheia. Dezactivarea validării verificării poate slăbi o verificare de securitate și nu ar trebui utilizată ca o soluție de producție.
O deschidere reușită a documentului verifică doar acea cale; repetați verificarea pentru fiecare gazdă WOPI și rută proxy pe care o utilizați.
Urmăriți erorile de verificare WOPI din Collabora până la chei nepotrivite, date de descoperire învechite, deviații de ceas sau modificări ale URL-ului proxy - fără a slăbi validarea.
Resetați zoom-ul browserului, testați o sesiune curată și identificați când un meniu cu dimensiune incorectă necesită o actualizare a serverului Collabora.
Implementează Collabora CODE cu Docker, conectează-l în siguranță la Nextcloud Office și verifică editarea documentelor cu verificări practice WOPI și proxy.
Creează temporar comanda coolwsd pentru depanare, capturează o deschidere eșuată și folosește secvența de jurnalizare pentru a separa problemele legate de WebSocket, WOPI, proxy și container.
Configurați datele de autentificare de administrator Collabora Online pentru Docker sau Linux, reporniți serviciul corect și verificați noua parolă fără a o expune.
Înainte de a modifica setările Collabora sau de a reporni serviciul, verificați dacă încărcarea CPU provine din documente active, procese de lucru inactive sau capacitatea serverului.
Verificați dacă Docker limitează CODUL Collabora, creșteți limita de memorie Compose în siguranță și confirmați că containerul care rulează a primit noua limită.
Simplificați CODE-ul Collabora cu modul Compact sau cu Tab-uri și controalele WOPI PostMessage pentru a ascunde în siguranță butoanele, comenzile și tab-urile selectate.
Puneți Nginx la conducerea HTTPS pentru un container de CODE Collabora, editați corect WebSocket-urile și verificați endpoint-ul public fără a expune portul 9980.
Depanați o tastatură de browser mobil care acoperă text în Collabora Online, cu soluții rapide și verificări separate pentru browsere, WebView-uri încorporate și pagini gazdă.
