„Validarea dovezii WOPI a eșuat” înseamnă că o gazdă WOPI nu a putut verifica o cerere semnată de la Collabora Online. Într-o configurație tipică Nextcloud Office, Nextcloud este gazda WOPI, iar Collabora este clientul WOPI: Collabora trimite cererea semnată, iar gazda o verifică. Formularea exactă variază în funcție de integrare și versiune, așadar, mai întâi identificați ce componentă a emis mesajul și ce cerere a eșuat.
Dovada este o verificare de securitate, nu un test general de conectivitate. Aceasta leagă o cerere de token-ul de acces, adresa URL completă a cererii și o marcă temporală, apoi semnează acele date cu cheia privată de dovadă a Collabora. Gazda verifică semnătura folosind o cheie publică de dovadă publicată în XML-ul de descoperire al Collabora. Definiția protocolului WOPI descrie câmpurile și anteturile semnate.
Prima acțiune: reproduceți eroarea o dată, notați ora, acțiunea fișierului, starea HTTP și ID-ul cererii sau corelației, apoi inspectați atât jurnalul platformei de stocare, cât și coolwsdjurnalul Collabora pentru același eveniment. Nu postați token-uri de acces, anteturi de probă sau chei private într-un tichet.
| Dovezi | Zona probabilă de inspectat | Acțiunea următoare |
|---|---|---|
| Eroarea a început după regenerarea sau înlocuirea cheii de probă Collabora | XML de descoperire memorat în memoria cache din partea de stocare sau cheie nepotrivită | Reîmprospătați descoperirea pe gazda WOPI și confirmați că aceasta vede cheia publică pentru instanța Collabora activă. |
| Eșecul apare doar la anumite solicitări sau intermitent | Mai multe noduri Collabora cu chei de probă diferite sau memorie cache de descoperire inconsistentă | Comparați valorile cheii de probă publicate de fiecare nod și verificați rutarea load-balancer-ului. |
| Eroarea apare după o modificare a proxy-ului, a numelui de gazdă sau a adresei URL | Adresă URL diferită pentru solicitare utilizată pentru semnare și verificare | Comparați adresa URL completă apelată de Collabora cu adresa URL utilizată de gazda WOPI pentru validarea dovezii. |
| Doar o gazdă sau o cale de rețea eșuează | Configurarea accesibilității, a proxy-ului invers sau a listei de permisiuni pentru gazde | Testați conectivitatea în ambele direcții și inspectați lista de permisiuni a gazdei WOPI separat de validarea dovezii. |
| Nicio modificare recentă a configurației, iar o marcă temporală de probă este respinsă. | Sincronizarea ceasului sau analiza/verificarea actualizării timestamp-urilor | Verificați ora UTC și starea NTP pe ambele sisteme; verificați interpretarea timestamp-ului gazdei și vârsta permisă. |
Collabora își publică capabilitățile WOPI și informațiile despre cheia de probă la punctul final de descoperire. De pe o mașină care poate accesa adresa URL Collabora utilizată de serverul dvs. de stocare, inspectați:
curl -fsS https://office.example.com/hosting/discoveryCăutați în XML un proof-keyelement cu o cheie curentă valueși, acolo unde este prezentă, o cheie oldvalue. Nu confundați acest material public cu cheia privată stocată pe serverul Collabora. Cea mai utilă comparație este răspunsul de descoperire preluat de gazda WOPI, deoarece un browser sau stația de lucru a unui administrator poate primi un răspuns diferit prin DNS, un proxy sau o memorie cache.
Verificat: Integrarea WOPI a Collabora utilizează semnături de probă, iar cheia publică este pusă la dispoziție prin descoperire. Acțiune: preluați descoperirea de la gazda/containerul real care validează cererile, apoi confirmați că XML-ul este valid și se potrivește cu endpoint-ul Collabora configurat în platforma de stocare. Ghidul de legare SharePoint Collabora descrie generarea cheilor de probă și comportamentul descoperirii.
În Collabora, verificați jurnalul de pornire pentru avertismente că fișierul cheie de probă lipsește sau este ilizibil. Serviciul Collabora trebuie să poată citi cheia privată pentru semnare. Pentru implementările în pachet, calea de configurare și contul de serviciu pot varia; verificați directorul configurat al serviciului și montările volumului containerului său, în loc să presupuneți o cale gazdă.
Documente Collabora coolconfig generate-proof-keypentru cazurile în care configurarea automată a cheii nu a funcționat. Nu o executați ca o comandă de depanare de rutină pe un cluster funcțional. Generarea unei chei noi modifică identitatea semnăturii. Dacă partea de stocare încă are încredere într-un răspuns de descoperire mai vechi, solicitările pot continua să eșueze până când gazda reîmprospătează cheia publică pe care o utilizează.
sudo coolconfig generate-proof-keyFolosește comanda respectivă numai după ce confirmi că cheia este absentă sau invalidă și după ce planifici modul în care fiecare nod Collabora și gazdă WOPI va primi informațiile cheii corespunzătoare. Apoi, urmează procedura de reîncărcare a serviciului documentată pentru implementarea pachetului sau a containerului și preia din nou descoperirea din calea de rețea a validatorului.
Un singur server Collabora poate funcționa în timp ce o implementare cu sarcină echilibrată eșuează intermitent. De exemplu, un nod poate avea o cheie privată nou generată, în timp ce altul semnează încă cu cheia veche; o gazdă cu date de descoperire stocate în cache s-ar putea să nu aibă încredere în niciuna dintre ele în mod constant. Aceasta este o cauză dependentă de implementare, nu o dovadă că fiecare eroare intermitentă este cauzată de rotația cheii.
Acțiune: preluați /hosting/discoveryprin echilibratorul de încărcare și direct din fiecare backend, dacă este permis. Comparați valorile cheii publice și verificați dacă memoria cache de descoperire a gazdei WOPI este actuală. Dacă nodurile utilizează intenționat chei separate, verificați dacă integrarea stocării acceptă acea topologie; în caz contrar, păstrați configurația cheii de probă consistentă în întregul cluster. Reîmprospătarea descoperirii ar trebui să utilizeze mecanismul acceptat de integrare. Evitați editarea memoriei cache a bazei de date sau repornirea serviciilor fără legătură fără dovezi.
Dovada acoperă adresa URL absolută a solicitării WOPI cu majuscule, precum și token-ul și marcajul temporal. Acest lucru face ca rescrierea adresei URL să fie relevantă. Un proxy invers poate schimba numele de gazdă, schema, portul, calea sau caracterul escape vizibile extern. Dacă Collabora semnează o solicitare pentru o adresă URL, dar gazda WOPI reconstruiește o adresă URL diferită pentru verificare, o semnătură corectă poate părea invalidă.
Acțiune: corelați o solicitare eșuată la nivelurile proxy și aplicație. Comparați schema, numele gazdei, portul explicit, calea și caracterele codificate văzute de validator cu adresa URL utilizată în codul de validare a dovezii. Verificați gestionarea forwarded-host și forwarded-proto numai dacă aplicația se bazează pe aceste anteturi. Păstrați adresa URL reală a solicitării; nu „remediați” problema dezactivând verificările semnăturilor sau acordând încredere anteturilor transmise arbitrar.
Dovada WOPI include X-WOPI-TimeStamp. În specificația Microsoft WOPI, acest antet este un număr întreg pe 64 de biți măsurat în intervale de 100 de nanosecunde începând cu 1 ianuarie 0001, nu o marcă temporală Unix în secunde. Un validator personalizat care îl analizează ca secunde Unix, elimină cifre, modifică codificarea sau asamblează incorect octeții semnați poate respinge cererile valide.
Abaterea de ceas este o cauză posibilă atunci când o gazdă impune o fereastră de prospețime, dar toleranța exactă depinde de implementarea de validare. Îndrumările Microsoft pentru Microsoft 365 pentru web utilizează o verificare a vechimii la 20 de minute; nu presupuneți că acest număr se aplică fiecărei integrări Collabora. Acțiune: verificați sincronizarea NTP și ora UTC pe sistemele Collabora și de stocare, apoi inspectați regula de marcaj temporal documentată a gazdei și codul de analiză.
Verificați și construcția la nivel de octet dacă mențineți o gazdă WOPI personalizată. Tokenul este UTF-8; lungimile reprezintă numărul de octeți; adresa URL este adresa URL absolută completă cu majuscule; iar valoarea timestamp-ului trebuie reprezentată exact așa cum este specificat. Cheia publică trebuie să corespundă cheii private utilizate de instanța Collabora care a trimis solicitarea.
O listă de gazde permise WOPI decide ce gazde de stocare are permisiunea Collabora să contacteze. Validarea TLS decide dacă certificatul unui peer de rețea este de încredere. Validarea dovezii verifică semnătura unei solicitări WOPI. Aceste controale sunt legate de integrarea securizată, dar nu sunt interschimbabile. Adăugarea unei gazde la o listă de gazde permise nu va repara o nepotrivire de semnătură; dezactivarea verificărilor TLS nu va corecta o cheie publică de probă învechită.
Pentru implementările Nextcloud, ghidul oficial de depanare recomandă verificarea căilor HTTP(S) necesare în ambele direcții, revizuirea jurnalelor Nextcloud și Collabora și confirmarea intrărilor din lista de permisiuni a gazdei WOPI pentru avertismente. Acțiune: urmați categoria de eroare din jurnal. Testați endpoint-ul de descoperire și accesibilitatea rețelei separat de validatorul de dovezi. Nu extindeți o listă de permisiuni *ca soluție alternativă.
Dacă eroarea persistă, colectați jurnale igienizate de la ambele părți, versiunile Collabora și de stocare, tipul de implementare, dacă sunt implicate unul sau mai multe noduri, XML-ul de descoperire cu secretele eliminate și ruta proxy pentru solicitarea eșuată. Partajați aceste informații cu furnizorul relevant sau cu administratorii integrării. Șirul exact de eroare nu stabilește dacă cauza este descoperirea învechită, canonizarea URL-ului, o problemă de ceas sau o eroare a validatorului personalizat; dovezile la nivel de solicitare determină ce cale trebuie urmată.
Utilizați setările de validare a datelor din Excel pentru a seta o lungime maximă, minimă, exactă sau un interval de caractere, apoi adăugați solicitări clare și alerte de eroare.
Creați o invitație la o întâlnire Outlook, adăugați participanți obligatorii sau opționali, alegeți o oră, adăugați detalii Teams, setați recurența și verificați răspunsurile în Outlook nou sau clasic.
Remediați eroarea „Nu putem programa întâlnirea” în Outlook verificând asistența pentru conturi, actualizând conectarea la Teams și reparând programul de completare Outlook clasic.
Modificați meniurile Office 365, setările de ortografie și gramatică sau introducerea de text de la tastatură în aplicațiile desktop și Microsoft 365 pentru web.
Aflați cum să redirecționați automat toate e-mailurile sau anumite e-mailuri în Outlook 365 folosind setările sau regulile de redirecționare, plus cum să opriți redirecționarea și să remediați redirecționările externe blocate.
Utilizați Editorul Microsoft în Word pentru Microsoft 365 pentru a verifica ortografia, gramatica, claritatea și concizia, a revizui sugestiile și a ajusta setările de verificare.
Aflați cum să adăugați un flux RSS în Outlook 365 în Outlook clasic pentru Windows, să găsiți adresa URL corectă a fluxului, să gestionați abonamentele și să remediați problemele comune legate de RSS.
Accesați direct orice pagină din Word pentru Microsoft 365 cu Ctrl+G sau F5, numere relative de pagină sau panoul de navigare, cu comenzi rapide pentru Windows și Mac.
Aflați cum să adăugați contacte în Outlook pe web, în noul Outlook, în Outlook clasic și în Outlook pentru mobil, plus cum funcționează sincronizarea contactelor și importurile în fișiere CSV.
Schimbați culoarea unei pagini Word, adăugați o imagine de fundal, eliminați oricare dintre ele și activați imprimarea în fundal pe Windows sau Mac cu pași clari și actuali.
