« Échec de la validation de la preuve WOPI » signifie qu'un hôte WOPI n'a pas pu vérifier une requête signée provenant de Collabora Online. Dans une configuration Nextcloud Office standard, Nextcloud fait office d'hôte WOPI et Collabora de client WOPI : Collabora envoie la requête signée, et l'hôte la vérifie. Le libellé exact varie selon l'intégration et la version ; il convient donc d'identifier au préalable le composant ayant émis le message et la requête ayant échoué.
La preuve constitue un contrôle de sécurité, et non un test de connectivité général. Elle associe une requête au jeton d'accès, à l'URL complète de la requête et à un horodatage, puis signe ces données avec la clé de preuve privée de Collabora. L'hôte vérifie la signature à l'aide d'une clé de preuve publique publiée dans le fichier XML de découverte de Collabora. La définition du protocole WOPI décrit les champs et en-têtes signés.
Première action : reproduire l’erreur une fois, noter l’heure, l’action sur le fichier, le statut HTTP et l’ID de requête ou de corrélation, puis consulter les journaux de la plateforme de stockage et de Collabora coolwsdpour cet événement. Ne communiquez pas les jetons d’accès, les en-têtes de preuve ni les clés privées dans un ticket.
| Preuve | Zone probable à inspecter | Action suivante |
|---|---|---|
| La panne a commencé après la régénération ou le remplacement de la clé de preuve de Collabora | XML de découverte mis en cache côté stockage ou clé non concordante | Actualisez la découverte sur l'hôte WOPI et vérifiez qu'il détecte bien la clé publique de l'instance Collabora active. |
| L'échec ne se produit que sur certaines requêtes ou de manière intermittente. | Plusieurs nœuds Collabora avec des clés de preuve différentes ou un cache de découverte incohérent | Comparez les valeurs des clés de preuve publiées par chaque nœud et vérifiez le routage de l'équilibreur de charge. |
| L'échec survient après une modification du proxy, du nom d'hôte ou de l'URL. | URL de requête différente utilisée pour la signature et la vérification | Comparez l'URL complète appelée par Collabora avec l'URL utilisée par l'hôte WOPI pour valider la preuve. |
| Un seul hôte ou un seul chemin réseau tombe en panne. | Configuration de la disponibilité, du proxy inverse ou de la liste blanche des hôtes | Tester la connectivité dans les deux sens et examiner la liste blanche des hôtes WOPI séparément de la validation des preuves. |
| Aucune modification récente de la configuration et un horodatage de preuve ne sont rejetés. | Synchronisation de l'horloge ou vérification de l'horodatage/de la fraîcheur | Vérifiez l'heure UTC et l'état NTP sur les deux systèmes ; vérifiez l'interprétation de l'horodatage de l'hôte et l'âge autorisé. |
Collabora publie ses capacités WOPI et les informations de sa clé de preuve sur le point de terminaison de découverte. Depuis une machine pouvant accéder à l'URL Collabora utilisée par votre serveur de stockage, examinez :
curl -fsS https://office.example.com/hosting/discoveryRecherchez dans le fichier XML un proof-keyélément contenant une valeur actuelle valueet, le cas échéant, une valeur oldvalue. Ne confondez pas ces informations publiques avec la clé privée stockée sur le serveur Collabora. La comparaison la plus pertinente est la réponse de découverte récupérée par l'hôte WOPI lui-même, car un navigateur ou le poste de travail d'un administrateur peut recevoir une réponse différente via le DNS, un proxy ou un cache.
Vérifié : L’intégration WOPI de Collabora utilise des signatures de preuve, et la clé publique est accessible via la découverte. Action : récupérez les données de découverte auprès de l’hôte/conteneur qui valide les requêtes, puis vérifiez que le XML est valide et correspond au point de terminaison Collabora configuré sur la plateforme de stockage. Le guide de liaison SharePoint de Collabora décrit la génération des clés de preuve et le fonctionnement de la découverte.
Sur Collabora, consultez le journal de démarrage pour détecter les avertissements indiquant que le fichier de clé de preuve est manquant ou illisible. Le service Collabora doit pouvoir lire la clé privée pour la signature. Pour les déploiements packagés, le chemin de configuration et le compte de service peuvent varier ; vérifiez le répertoire configuré du service et ses points de montage de volume de conteneur plutôt que de supposer un chemin sur l'hôte.
La documentation Collabora coolconfig generate-proof-keydécrit les cas où la configuration automatique des clés a échoué. Ne l'exécutez pas comme commande de dépannage de routine sur un cluster en fonctionnement. La génération d'une nouvelle clé modifie l'identité de signature. Si le système de stockage fait toujours confiance à une ancienne réponse de découverte, les requêtes peuvent continuer d'échouer jusqu'à ce que l'hôte actualise sa clé publique.
sudo coolconfig generate-proof-keyN'utilisez cette commande qu'après avoir vérifié l'absence ou l'invalidité de la clé et après avoir défini comment chaque nœud Collabora et hôte WOPI recevra les informations de clé correspondantes. Suivez ensuite la procédure de rechargement de service documentée pour votre déploiement de package ou de conteneur et relancez la découverte depuis le chemin réseau du validateur.
Un serveur Collabora unique peut fonctionner correctement tandis qu'un déploiement à charge équilibrée présente des défaillances intermittentes. Par exemple, un nœud peut disposer d'une clé privée nouvellement générée tandis qu'un autre utilise encore l'ancienne clé ; un hôte disposant de données de découverte mises en cache peut ne faire confiance à aucune des deux de manière cohérente. Il s'agit d'une cause liée au déploiement, et non d'une preuve que chaque erreur intermittente est due à la rotation des clés.
Action : récupérer les données /hosting/discoveryvia l’équilibreur de charge et directement depuis chaque serveur dorsal, si autorisé. Comparer les valeurs des clés publiques et vérifier que le cache de découverte de l’hôte WOPI est à jour. Si les nœuds utilisent intentionnellement des clés distinctes, vérifier que l’intégration de stockage prend en charge cette topologie ; sinon, maintenir une configuration de clés de preuve cohérente sur l’ensemble du cluster. L’actualisation de la découverte doit utiliser le mécanisme pris en charge par l’intégration. Éviter de modifier un cache de base de données ou de redémarrer des services non liés sans justification.
La preuve inclut l'URL complète de la requête WOPI en majuscules, ainsi que le jeton et l'horodatage. La réécriture d'URL est donc pertinente. Un proxy inverse peut modifier le nom d'hôte, le schéma, le port, le chemin ou les caractères d'échappement visibles de l'extérieur. Si Collabora signe une requête pour une URL, mais que l'hôte WOPI en reconstruit une différente pour vérification, une signature correcte peut apparaître comme invalide.
Action : corréler une requête ayant échoué aux niveaux proxy et application. Comparer le schéma, le nom d’hôte, le port explicite, le chemin et les caractères encodés vus par le validateur avec l’URL utilisée dans le code de validation. Vérifier la gestion des en-têtes forwarded-host et forwarded-proto uniquement si l’application s’appuie sur ces en-têtes. Conserver l’URL de la requête réelle ; ne pas « corriger » le problème en désactivant les vérifications de signature ou en faisant confiance à des en-têtes forwarded arbitraires.
La preuve WOPI inclut un en-tête X-WOPI-TimeStamp. Dans la spécification Microsoft WOPI, cet en-tête est un entier 64 bits mesuré par intervalles de 100 nanosecondes depuis le 1er janvier 0001, et non un horodatage Unix en secondes. Un validateur personnalisé qui l'interprète comme des secondes Unix, omet des chiffres, modifie l'encodage ou assemble incorrectement les octets signés peut rejeter des requêtes valides.
Un décalage horaire peut être à l'origine d'un problème lorsqu'un hébergeur impose une période de validité des données, mais la tolérance exacte dépend de l'implémentation de validation. Les recommandations de Microsoft pour Microsoft 365 pour le Web préconisent une vérification de l'ancienneté toutes les 20 minutes ; cette valeur ne s'applique pas nécessairement à toutes les intégrations Collabora. Action : vérifiez la synchronisation NTP et l'heure UTC sur les systèmes Collabora et de stockage, puis examinez la règle d'horodatage et le code d'analyse de l'hébergeur.
Vérifiez également la structure au niveau octet si vous utilisez un hôte WOPI personnalisé. Le jeton est encodé en UTF-8 ; les longueurs correspondent au nombre d’octets ; l’URL est l’URL absolue complète en majuscules ; et la valeur de l’horodatage doit être représentée exactement comme spécifié. La clé publique doit correspondre à la clé privée utilisée par l’instance Collabora qui a envoyé la requête.
Une liste blanche d'hôtes WOPI détermine les hôtes de stockage que Collabora est autorisé à contacter. La validation TLS détermine si le certificat d'un homologue du réseau est fiable. La validation de la preuve vérifie la signature d'une requête WOPI. Ces contrôles sont liés à l'intégration sécurisée, mais ne sont pas interchangeables. Ajouter un hôte à une liste blanche ne résoudra pas un problème de signature ; désactiver les vérifications TLS ne corrigera pas une clé de preuve publique obsolète.
Pour les déploiements Nextcloud, le guide de dépannage officiel recommande de vérifier les chemins HTTP(S) requis dans les deux sens, de consulter les journaux Nextcloud et Collabora, et de confirmer les entrées de la liste blanche WOPI pour les avertissements relatifs à cette liste. Action : suivez la catégorie d’erreur indiquée dans le journal. Testez le point de terminaison de découverte et l’accessibilité réseau indépendamment du validateur de preuve. N’élargissez pas la liste blanche à *titre de solution de contournement.
Si l'erreur persiste, collectez les journaux anonymisés des deux extrémités, les versions de Collabora et du stockage, le type de déploiement, le nombre de nœuds impliqués, le fichier XML de découverte (sans les secrets) et la route du proxy pour la requête ayant échoué. Partagez ces informations avec le fournisseur ou les responsables de l'intégration concernés. Le message d'erreur exact ne permet pas à lui seul de déterminer si la cause est une découverte obsolète, un problème de canonisation d'URL, un problème d'horloge ou un bug d'un validateur personnalisé ; les informations au niveau de la requête déterminent la piste à suivre.
Connectez les éditeurs de bureau ONLYOFFICE à votre serveur ownCloud, connectez-vous, ouvrez des fichiers cloud, gérez la connexion et résolvez les problèmes de configuration courants.
Résolvez les problèmes d'utilisation élevée du processeur de Collabora Online en identifiant les processus du kit occupés, en vérifiant les indicateurs et les journaux, en ajustant la concurrence et le nettoyage, et en vérifiant les correctifs en toute sécurité.
Découvrez comment personnaliser ONLYOFFICE Docs avec un logo d'en-tête et des couleurs d'interface, y compris les limites de licence, la configuration JSON du thème, les chemins Docker et les tests.
Corrigez les textes difficiles à lire dans LibreOffice Calc en vérifiant le thème de l'application, la police et les couleurs de remplissage des cellules, les styles et la mise en forme conditionnelle, puis vérifiez le résultat d'impression.
Débloquez en toute sécurité l'avertissement de verrouillage par utilisateur inconnu de LibreOffice. Vérifiez les sessions actives, protégez une copie, supprimez uniquement un verrouillage obsolète vérifié et testez le document.
Corrigez les problèmes de mise en page du texte arabe ou hébreu avec l'anglais dans LibreOffice Writer. Activez la mise en page complexe, définissez le sens des paragraphes et vérifiez le résultat.
Learn VLOOKUP and XLOOKUP in LibreOffice Calc, including exact matches, left lookups, not-found results, reverse search, INDEX/MATCH alternatives, and common errors.
Résolvez les problèmes de validation des preuves WOPI de Collabora Online en vérifiant les clés de découverte, la rotation des clés, les URL proxy, les horodatages et les listes d'autorisation des hôtes.
Activez le suivi des modifications pour tous les utilisateurs dans un document ONLYOFFICE, maintenez-le actif après la réouverture et comprenez les limites d'une option par défaut globale.
Comparez les délais d'expiration par vue, hors focus, d'inactivité des documents, de sauvegarde automatique et de proxy de Collabora Online, puis choisissez et vérifiez les paramètres pour votre déploiement.
