Lorsqu'un hôte WOPI signale « Échec de la validation de la preuve » ou « Preuve WOPI invalide », vérifiez d'abord quel système a enregistré le rejet. Si l'hôte de stockage rejette la requête signée de Collabora, vérifiez la paire de clés de preuve et la réponse de découverte avant de modifier les listes blanches des hôtes WOPI ou de désactiver les vérifications de preuve. Pour les installations de paquets, Collabora génère généralement la paire de clés ; pour les déploiements Docker, Kubernetes et multi-répliques, la paire doit être fournie et conservée de manière cohérente.
La validation de preuve WOPI utilise une requête signée et la clé publique annoncée par le client WOPI dans ses métadonnées de découverte. Elle est indépendante de la liste des hôtes WOPI de confiance de Collabora, de la validation du certificat TLS et de la vérification du jeton d'accès de l'hôte de stockage. La régénération de clé peut s'avérer utile lorsque la clé privée est manquante ou ne correspond pas à la clé publique annoncée, mais elle peut engendrer une nouvelle incohérence si une seule réplique est modifiée ou si un hôte conserve des données de découverte en cache.
| Preuves dans le journal | Zone probable à vérifier |
|---|---|
| Le serveur de stockage indique « Preuve WOPI invalide » lors de la réception d'une requête CheckFileInfo ou d'une autre requête WOPI. | La clé de preuve de Collabora, les données de découverte de l'hôte, la reconstruction de l'URL ou l'horodatage |
| Collabora indique « Hôte WOPI non autorisé » ou « Aucun hôte WOPI acceptable ». | La liste blanche des hôtes WOPI / la configuration du domaine, et non la clé de preuve |
| Jeton invalide, expiré ou accès refusé sans preuve d'erreur | Jeton d'accès émis par l'hôte, autorisations ou expiration du jeton |
Vérifiez une requête ayant échoué dans les journaux de Collabora et de l'hôte de stockage ; un indicateur de chargement du navigateur ne suffit pas à identifier un échec de clé de preuve.
Commencez par l'option la moins perturbatrice. Lors d'une installation par paquet, vérifiez d'abord les fichiers clés existants et les journaux de service ; la documentation Collabora actuelle indique que les installations par paquet RPM et Debian génèrent automatiquement une paire de clés WOPI. Si ces fichiers sont présents et stables, leur renouvellement est généralement inutile.
| Déploiement | Action recommandée | Compromis |
|---|---|---|
| Serveur géré par un seul paquet | Conservez la paire de clés générée ; réparez les autorisations ou régénérez-les uniquement si elles sont manquantes ou incompatibles. | Modifications minimes, mais vérifiez la version de votre paquet et les chemins configurés. |
| Conteneur Docker unique | Générez une paire une seule fois et montez-la de manière permanente dans le conteneur. | Nécessite un volume persistant et un accès en lecture correct pour coolwsd |
| Kubernetes ou plusieurs répliques | Montez une paire de clés/secrets partagée dans chaque instance Collabora | Signatures cohérentes entre les répliques ; la rotation doit également mettre à jour la vue de découverte de l’hôte. |
| L'URL de l'hôte a été modifiée derrière un proxy | Vérifiez le schéma public, l'hôte, le chemin et la chaîne de requête utilisés pour la validation de la signature. | Plus complexe que la rotation de clés, mais évite les changements d'identifiants inutiles. |
Le manuel de Collabora 24.04 indique que l'image Docker publique ne contient pas de paire de clés de preuve ; il est donc recommandé d'en générer une et de la monter de manière permanente. Le graphique Helm officiel prend en charge les secrets de clé de preuve. Il est fortement déconseillé de générer une paire distincte pour chaque réplique, car l'équilibrage de charge peut entraîner des pannes intermittentes.
coolwsd.xmlparamètres du chemin d'accès à la clé de preuve et vérifiez que la clé privée et la clé publique sont bien présentes. Elles se trouvent généralement sous `/etc/keys` /etc/coolwsd/, mais l'organisation des packages et des conteneurs peut varier. Ne collez jamais la clé privée dans les journaux, les tickets ou le chat.sudo openssl pkey -in /etc/coolwsd/proof_key -pubout -outform DER | sha256sumet openssl pkey -pubin -in /etc/coolwsd/proof_key.pub -outform DER | sha256sum`<chemin_par_défaut>`. Les hachages obtenus doivent correspondre. Si vos chemins diffèrent, remplacez-les par les chemins réellement configurés. Si la clé privée est illisible, corrigez son propriétaire et ses permissions conformément au modèle de sécurité du service ; ne la rendez pas accessible à tous.sudo coolconfig generate-proof-keyl'utilitaire d'installation. Pour Docker, générez la paire dans un emplacement persistant approprié, puis montez les deux fichiers à l'endroit où Collabora les attend et assurez-vous que le processus coolwsd peut lire la clé privée. Sur une plateforme gérée, utilisez le mécanisme de gestion des secrets plutôt que de modifier manuellement un pod en cours d'exécution.
Vérifiez la synchronisation horaire sur les deux systèmes. Les requêtes de preuve WOPI incluent un horodatage ; un hôte peut rejeter un horodatage ancien ou hors plage horaire. Assurez-vous que le service NTP ou le service de temps de la plateforme fonctionne correctement et que les serveurs renvoient des heures UTC cohérentes. Ne désactivez pas les contrôles d'horodatage pour contourner un problème d'horloge.
Ensuite, examinez l'URL publique utilisée par l'hôte pour reconstituer la requête signée. La preuve est liée à l'URL de la requête, y compris aux paramètres de requête pertinents, et la spécification WOPI exige que la représentation URL utilisée pour la validation corresponde à la forme signée. Un proxy inverse terminant le HTTPS peut faire en sorte que l'application voie une URL HTTP interne, même si Collabora a signé l'URL HTTPS publique. Configurez les en-têtes de proxy de confiance et les paramètres d'URL externes de l'application conformément aux recommandations officielles de l'hôte WOPI ; ne modifiez pas la logique de preuve et ne supprimez pas les paramètres de requête.
Si la validation échoue uniquement après une rotation de clé, actualisez la découverte et vérifiez que toutes les répliques Collabora exposent la même clé publique. Si seules les requêtes acheminées via un proxy ou une réplique échouent, comparez les journaux et la configuration de ce chemin plutôt que de procéder à une nouvelle rotation de clé. La désactivation de la validation peut affaiblir un contrôle de sécurité et ne doit pas être utilisée comme solution de contournement en production.
L'ouverture réussie d'un document vérifie uniquement ce chemin ; répétez la vérification pour chaque hôte WOPI et route proxy que vous utilisez.
Détecter les échecs de preuve WOPI de Collabora dus à des clés non concordantes, des données de découverte obsolètes, une dérive d'horloge ou des modifications d'URL de proxy, sans affaiblir la validation.
Réinitialisez le zoom du navigateur, testez une session propre et identifiez quand un menu de taille incorrecte nécessite une mise à jour du serveur Collabora.
Déployez Collabora CODE avec Docker, connectez-le en toute sécurité à Nextcloud Office et vérifiez l'édition de documents grâce à des contrôles WOPI et proxy pratiques.
Activez temporairement coolwsd pour le débogage, capturez une ouverture ayant échoué et utilisez la séquence de journaux pour distinguer les problèmes WebSocket, WOPI, proxy et conteneur.
Configurez la connexion d'administrateur Collabora Online pour Docker ou Linux, redémarrez le service approprié et vérifiez le nouveau mot de passe sans le divulguer.
Avant de modifier les paramètres de Collabora ou de redémarrer le service, vérifiez si la charge du processeur provient de documents actifs, de processus de travail inactifs ou de la capacité du serveur.
Vérifiez si Docker limite la mémoire de Collabora CODE, augmentez la limite de mémoire de Compose en toute sécurité et confirmez que le conteneur en cours d'exécution a bien reçu la nouvelle limite.
Simplifiez Collabora CODE grâce au mode Compact ou à onglets et aux contrôles WOPI PostMessage pour masquer en toute sécurité les boutons, commandes et onglets sélectionnés.
Confiez la gestion du HTTPS à Nginx pour un conteneur Collabora CODE, configurez correctement l'édition des WebSockets et vérifiez le point de terminaison public sans exposer le port 9980.
Dépannage des problèmes de masquage du texte par le clavier d'un navigateur mobile dans Collabora Online, avec des solutions de contournement rapides et des vérifications distinctes pour les navigateurs, les WebViews intégrées et les pages hôtes.
