Remediați eroarea de conexiune Collabora Online „Ei bine, asta e jenant”

Mesajul Collabora Online „Ei bine, este jenant, nu ne putem conecta la documentul dvs.” este un simptom, nu un diagnostic. Apare după ce se încarcă shell-ul editorului, dar sesiunea documentului nu se poate finaliza. În implementările actuale, cea mai rapidă modalitate de a remedia problema este de a identifica ce conexiune din calea WOPI eșuează, în loc să modificați setările aleatorii Collabora.

Acest ghid folosește documentația actuală de administrare Nextcloud 35 și îndrumările SDK-ului 25.04 de la Collabora Online ca puncte de referință. Aceeași logică de depanare se aplică multor integrări ownCloud și WOPI personalizate, dar numele exacte ale setărilor pot diferi în funcție de platformă și versiune.

Ce cauzează de obicei această eroare de conexiune Collabora?

O sesiune funcțională de browser depinde de mai multe căi separate. Browserul utilizatorului trebuie să ajungă atât la serverul de stocare, cât și la Collabora; serverul de stocare trebuie să ajungă la Collabora; Collabora trebuie să ajungă la serverul de stocare; protocoalele și certificatele trebuie să fie compatibile; iar proxy-ul invers trebuie să redirecționeze corect rutele HTTP și WebSocket ale Collabora. Pagina oficială de depanare a Nextcloud listează explicit aceste cerințe de accesibilitate bidirecțională.

Asta înseamnă că nu există o singură soluție universal corectă. Alegeți calea de reparare pe baza primului test eșuat:

1. Verificați punctele finale de descoperire și funcționalități Collabora

Începeți cu adresa URL publică Collabora pe care o folosește de fapt integrarea dvs. Deschideți aceste puncte finale într-un browser și de pe serverul de stocare:

https://office.example.com/hosting/discovery
https://office.example.com/hosting/capabilities

Documentația actuală de depanare a Nextcloud recomandă ambele teste. Punctul final de descoperire ar trebui să returneze XML, în timp ce capabilitățile returnează date despre capabilitățile Collabora. O expirare, un avertisment de certificat, o eroare 404, o pagină de eroare cu proxy sau o buclă de redirecționare înseamnă că ar trebui să remediați rețeaua sau proxy-ul invers înainte de a atinge setările WOPI.

Verificați mai întâi adresele URL publice Collabora pentru descoperire și capabilități; ambele trebuie să fie accesibile prin același nume de gazdă utilizat de integrare.

Pentru îndrumări autorizate privind endpoint-urile, consultați depanarea Nextcloud Office și manualul Collabora Online 25.04 SDK .

2. Testați toate cele patru direcții de rețea, nu doar browserul

O greșeală frecventă este presupunerea că, deoarece office.example.comse deschide într-un browser desktop, Collabora poate prelua fișiere și de pe serverul de stocare. Acest lucru nu este garantat. Testați de pe gazdele sau containerele reale:

# From the Nextcloud/storage server
curl -fsS https://office.example.com/hosting/discovery >/dev/null && echo OK

# From the Collabora host/container
curl -fsS https://cloud.example.com/status.php

# Then inspect Collabora logs
docker logs --tail 100 collabora

Dacă numele public de gazdă se rezolvă diferit în Docker, Kubernetes sau o rețea privată, decideți dacă să remediați DNS-ul intern, să adăugați o mapare adecvată a gazdei sau să rutați prin endpoint-ul public. DNS-ul intern este de obicei mai curat la scară largă; o intrare în fișierul hosts este rapidă pentru o instalare statică mică, dar devine mai greu de întreținut.

Rulați teste de accesibilitate chiar de pe servere, apoi utilizați jurnalul Collabora pentru a separa o eroare de rețea de o eroare de încredere WOPI.

3. Remediați proxy-ul invers dacă lipsesc rutele WebSockets sau Collabora

Collabora nu este o aplicație web statică obișnuită. Proxy-ul său invers are nevoie de rute pentru resursele browserului, descoperire/capacități, traficul de documente și WebSocket-uri. În manualul SDK-ului Collabora, exemplul Nginx redirecționează /browser, /hosting/discovery, /hosting/capabilities, /cool/.../wscalea WebSocket și traficul aferent /coolsau /lool.

Pentru ruta WebSocket, proxy-ul trebuie să păstreze gazda și să transmită actualizarea HTTP. Un model Nginx simplificat este:

location ~ ^/cool/(.*)/ws$ {
    proxy_pass http://127.0.0.1:9980;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 36000s;
}

Nu copiați acest lucru orbește dacă terminați TLS în mod diferit. Collabora documentează modele separate pentru terminarea end-to-end TLS și SSL. Dacă TLS se termină la Nginx și conexiunea backend este HTTP, setările SSL interne ale Collabora trebuie să corespundă acelui design. Utilizarea HTTPS peste tot este mai simplă de raționat, în timp ce terminarea TLS la proxy reduce gestionarea certificatelor în interiorul containerelor, dar introduce o altă limită de configurare.

Un proxy invers corect trebuie să redirecționeze rutele HTTP Collabora și să păstreze actualizarea WebSocket pentru sesiunea de documente.

4. Verificați consecvența protocolului, certificatului și numelui de gazdă

Documentația actuală de configurare Office a Nextcloud precizează că serverul Collabora Online ar trebui să utilizeze același protocol ca și instalarea Nextcloud, fiind recomandat HTTPS. În practică, configurațiile mixte HTTP/HTTPS publice pot declanșa conținut blocat, ținte de redirecționare greșite sau erori de validare a certificatelor backend.

Verificați împreună aceste elemente:

• URL-ul Collabora salvat pe platforma dvs. de stocare este exact URL-ul public la care ajung utilizatorii.
• Certificatul prezentat de numele de gazdă respectiv este valid pentru numele de gazdă și este considerat de încredere de către serverul de stocare.
• Collabora poate valida certificatul HTTPS al serverului de stocare.
• Proxy-ul invers redirecționează corect gazda și schema originale.
• Nu există nicio redirecționare de la numele de gazdă Collabora configurat către un alt nume de gazdă pe care WOPI nu o așteaptă.

Un certificat autosemnat poate fi acceptabil într-un laborator dacă fiecare componentă este configurată explicit să aibă încredere în acesta, dar această comoditate compromite portabilitatea și cauzează frecvent eșecul ulterioar al actualizărilor sau al reconstruirii containerelor. Pentru producție, un lanț de certificate de încredere publică sau de încredere organizațională este alegerea mai sigură.

5. Corectați listele de permisiuni WOPI în loc să le dezactivați

Dacă detectarea funcționează și jurnalele Collabora afișează mesaje precum „ Unauthorized WOPI hostnicio gazdă WOPI acceptabilă care să corespundă țintei”, problema a trecut de la conectivitatea de bază la configurația de încredere. Documentația oficială de depanare Nextcloud îi îndrumă în mod specific pe administratori către jurnalele containerelor pentru acest caz.

În ceea ce privește stocarea, Nextcloud recomandă restricționarea solicitărilor WOPI la adresele IP ale serverelor Collabora folosind setarea Listă permisă pentru solicitări WOPI . În ceea ce privește Collabora, gazdele de stocare WOPI permise trebuie să corespundă cu adresele URL de stocare pe care Collabora le primește efectiv. Pentru domenii de stocare multiple, SDK-ul actual al Collabora documentează grupurile de alias WOPI.

Păstrați adresa URL a serverului Collabora și lista de permisiuni WOPI aliniate cu implementarea reală; utilizați intrări de încredere restrânse în loc să dezactivați validarea.

Consultați configurația Nextcloud Office pentru adresa URL a serverului curent și instrucțiunile privind lista de acces permise WOPI. Dacă utilizați ownCloud Infinite Scale, serviciul său de colaborare utilizează COLLABORATION_APP_ADDRadresa URL a aplicației Office și COLLABORATION_WOPI_SRCsursa WOPI accesibilă extern; consultați documentația serviciului de colaborare ownCloud .

Când ar trebui să utilizați CODUL încorporat în loc de un server Collabora separat?

Pentru o instalare Nextcloud mică, serverul CODE încorporat reduce numărul de componente gestionate extern. Compromisul este că depinde în continuare de posibilitatea ca instanța Nextcloud să se conecteze la ea însăși prin intermediul numelui de gazdă utilizat în browser. Documentația de depanare Nextcloud menționează acest lucru direct și sugerează rezolvarea corectă a numelui de gazdă respectiv atunci când serverul CODE încorporat nu se poate conecta.

Un server Collabora separat este de obicei o alegere mai potrivită atunci când aveți nevoie de scalare independentă, servicii centralizate pentru mai multe instanțe de stocare sau o arhitectură de producție cu limite mai clare ale resurselor. Acesta adaugă configurații DNS, proxy, certificat, firewall și WOPI trust, astfel încât sarcina operațională este mai mare.

Ce să nu faci

• Nu dezactivați validarea WOPI ca primă soluție. Aceasta poate ascunde nepotrivirea numelui de gazdă și poate slăbi o limită de securitate.
• Nu expuneți portul 9980 direct doar pentru că proxy-ul se defectează. Remediați proxy-ul cu excepția cazului în care expunerea directă este un design intenționat și securizat.
• Nu presupuneți că un răspuns de 200 de puncte de pe pagina principală Collabora dovedește că editarea documentelor funcționează. Descoperirea, capabilitățile, accesul la fișiere WOPI și WebSockets sunt căi separate.
• Nu modificați mai multe straturi simultan. Testați după fiecare modificare pentru a ști dacă DNS, TLS, proxy-ul sau încrederea WOPI a fost cauza reală.

Lista de verificare finală

După efectuarea unei modificări, verificați sistemul în această ordine:

1. Deschideți /hosting/discoveryși /hosting/capabilitiesdintr-un browser.
2. Preluați aceleași puncte finale de pe serverul de stocare.
3. De pe serverul Collabora, obțineți adresa URL de stare a serverului de stocare.
4. Deschideți un document în timp ce urmăriți atât jurnalele Collabora, cât și jurnalele de stocare.
5. Confirmați că browserul stabilește Collabora WebSocket fără deconectări repetate.
6. Confirmați că un al doilea utilizator poate deschide și edita un document de test dacă este necesară editarea colaborativă.

Dacă toate cele șase verificări reușesc, mesajul generic „Ei bine, asta e jenant” nu ar trebui să mai mascheze o eroare de conexiune. Dacă mesajul persistă, capturați liniile exacte ale jurnalului Collabora și eroarea de rețea a browserului pentru o singură încercare de deschidere a documentului; aceste două dovezi sunt mai utile decât mesajul generic al interfeței utilizator în sine.