Dacă Nextcloud raportează „Tokenul nu este valid” atunci când se conectează la ONLYOFFICE Docs, faceți ca secretul JWT al conectorului să corespundă cu secretul utilizat de fapt de Document Server. În ONLYOFFICE Docs 7.2 și versiunile ulterioare, validarea JWT este activată în mod implicit și un secret este generat automat; modificarea doar a setării Nextcloud sau editarea fișierului de configurare generat de un container Docker poate lăsa cele două părți nesincronizate.
Mențineți JWT activat. Mai întâi identificați secretul activ și tipul de implementare, actualizați configurația corectă, apoi rulați verificarea conexiunii conectorului. Verificarea ar trebui să raporteze o conexiune reușită; deschiderea editorului de browser nu dovedește că descărcările de documente și apelurile inverse funcționează.
JWT (JSON Web Token) este un token semnat folosit pentru a verifica dacă o cerere între Nextcloud și ONLYOFFICE Docs este de încredere. Conectorul semnează cererile cu secretul său configurat, în timp ce Document Server le validează folosind secretul său configurat. Dacă secretele de semnare diferă, semnătura token nu poate fi validată, iar cererea este respinsă.
Cele mai frecvente cauze sunt un secret copiat dintr-o instalare veche, un secret generat automat care nu a fost introdus niciodată în Nextcloud, o variabilă de mediu Docker modificată care nu a fost aplicată prin recrearea containerului sau valori inconsistente ale secretului în configurația Document Server. Un antet JWT personalizat poate cauza, de asemenea, o nepotrivire dacă conectorul și Document Server nu utilizează același nume de antet.
Acest articol abordează problema nepotrivirii JWT. Dacă eroarea spune în schimb că serverul nu poate fi accesat, certificatul este invalid sau un document nu poate fi descărcat, investigați separat adresele serverului, certificatul TLS și calea de rețea Nextcloud-to-Document-Server. O corecție JWT nu va repara aceste condiții.
Folosește configurația care aparține serverului de documente care rulează. Nu presupune că un secret reținut dintr-un container sau server anterior este încă activ.
/etc/onlyoffice/documentserver/local.json.%ProgramFiles%\ONLYOFFICE\DocumentServer\config\local.json.sudo docker exec <containerID> /var/www/onlyoffice/documentserver/npm/json -f /etc/onlyoffice/documentserver/local.json 'services.CoAuthoring.secret.session.string'Înlocuiți <containerID>cu numele sau ID-ul real al containerului. Tratați valoarea returnată ca pe o acreditare: nu o lipiți în forumurile de asistență, capturi de ecran sau jurnalele publice.
În local.json, comparați valorile din services.CoAuthoring.secret.inbox.string, services.CoAuthoring.secret.outbox.stringși services.CoAuthoring.secret.session.string. Toate ar trebui să fie identice pentru această configurație standard. De asemenea, confirmați că validarea token-urilor este activată pentru browser, inbox-ul de solicitări și outbox-ul de solicitări. Versiunile Docs anterioare versiunii 7.2 necesită activarea explicită a validării token-urilor; versiunile ulterioare o activează în mod implicit.
jwt_headerși antetul token-ului configurat al serverului de documente trebuie să coincidă. Dacă nu ați personalizat antetul în mod intenționat, nu îl modificați ca parte a acestei reparații.Setarea documentată a conectorului poate fi modificată și cu comanda Nextcloud occdin directorul de instalare Nextcloud:
sudo -u www-data php occ config:app:set onlyoffice jwt_secret --value='YOUR_SECRET'Înlocuiți YOUR_SECRETcu valoarea reală. Citarea în shell ajută la păstrarea punctuației, dar secretele care conțin o singură citare necesită o metodă mai sigură decât inserarea lor directă într-o linie de comandă. Argumentele din linia de comandă pot fi, de asemenea, vizibile pentru inspecția proceselor privilegiate sau istoricul shell-ului. Preferați interfața de administrator acolo unde este practic, apoi verificați valoarea stocată fără a o expune.
Pentru implementările Docker, configurați JWT prin mediul containerului, în loc să editați manual codul secret generat automat local.json. Setați același secret în definiția serviciului Document Server:
environment:
- JWT_ENABLED=true
- JWT_SECRET=YOUR_SECRETDupă modificarea fișierului Compose, recreați containerul Document Server astfel încât mediul să aibă efect. De exemplu, din directorul care conține fișierul Compose:
docker compose up -d --force-recreate <documentserver-service>Înlocuiți numele serviciului din propriul fișier Compose. O repornire simplă nu aplică o valoare de mediu modificată unui container existent. Dacă utilizați docker run, recreați containerul cu valorile actualizate JWT_ENABLEDși JWT_SECRET, păstrând porturile, volumele și alte opțiuni necesare existente. Nu ștergeți un container de producție până când nu ați confirmat aceste setări și montările persistente de date.
Când containerul pornește, recitiți secretul său activ cu comanda de mai sus și asigurați-vă că valoarea se potrivește în continuare cu Nextcloud. Evitați plasarea unui secret de producție într-un fișier Compose partajat public sau într-un depozit sursă.
Dacă setați intenționat un secret personalizat în local.json, asigurați-vă că cele trei câmpuri de secret se potrivesc și că valorile de validare a token-urilor necesare sunt activate. Aplicați modificarea repornind serviciile relevante ale serverului de documente. Lista de instrucțiuni ONLYOFFICE curente include ds-converter, ds-docservice, și ds-metricspe Linux; instalările gestionate de un alt supervizor de servicii pot necesita metoda de repornire corespunzătoare configurării respective. Pe Windows, reporniți serviciile ONLYOFFICE după salvarea configurației.
O nepotrivire care reapare după repornire înseamnă de obicei că o configurație generată sau un mediu de implementare are prioritate față de fișierul editat. Pentru Docker, mutați corecția în variabilele de mediu și recreați containerul. Pentru implementările pachetizate, inspectați configurația activă și configurația de pornire a serviciului înainte de a modifica mai multe setări.
sudo -u www-data php occ onlyoffice:documentserver --checkFolosește contul de server web corespunzător instalării tale dacă nu este www-data. Comanda ar trebui să raporteze o conexiune reușită. Dacă raportează în continuare un token nevalid, confirmă din nou că secretul activ al serverului de documente care rulează se potrivește exact cu Nextcloud și că orice antet JWT personalizat este de acord.
Aceste verificări stabilesc dacă conexiunea configurată și o cale de salvare de bază funcționează. Nu dovedesc că fiecare rută de proxy invers, configurație de stocare externă sau topologie multi-server este corectă; testați acele căi separat dacă implementarea le utilizează.
Detaliile de configurare au fost verificate în raport cu documentația oficială ONLYOFFICE și cu depozitul de conectori pe 9 octombrie 2026. Etichetele interfeței utilizator și gestionarea serviciilor pot varia în funcție de conector, sistem de operare și metodă de implementare.
Separă problemele legate de descărcarea browserului de erorile de conversie de pe server și folosește jurnalul corect sau verificarea accesului pentru a face exportul PDF să funcționeze.
Potrivește secretul JWT utilizat de ONLYOFFICE Docs și Nextcloud, aplică-l în siguranță pentru instalările Docker sau Linux și verifică conexiunea fără a slăbi autentificarea.
Instalați ONLYOFFICE Workspace Community pe Ubuntu 24.04 cu scriptul oficial Docker, verificați cerințele serverului, omiteți Mail dacă este necesar și verificați portalul în siguranță.
Configurați secrete JWT corespunzătoare pentru ONLYOFFICE Docs și conectorul său, cu pași siguri pentru pachete Linux, implementări Docker și verificare.
Dați unui editor ONLYOFFICE Docs încorporat sigla companiei și culorile interfeței, cu un fișier temă personalizat și o configurație a editorului. Consultați limitele de ediție și verificările de implementare.
Urmăriți editările în Writer, păstrați o sursă ODT editabilă și verificați fișierul DOCX exportat în Word înainte de a-l partaja.
Urmați procedura SP7 a SUSE pentru a activa modul FIPS, reporniți în siguranță, verificați politica activă și verificați dacă cerința de conformitate necesită module validate.
Comparați YaST și cryptsetup pentru un nou volum de date SLES criptat, alegeți LUKS1 sau LUKS2 și verificați comportamentul de deblocare și montare în siguranță.
Configurați RMT pe SLES 15, oglindiți repozitoriile autorizate și verificați înregistrarea HTTPS și accesul la pachet de la un client de testare.
Conectați SLES 15 la AD cu ajutorul gestionării logon-ului bazate pe SSSD din YaST, apoi verificați căutarea în directoare, conectarea la domeniu și tichetele Kerberos.
