Résoudre l'erreur de connexion « C'est embarrassant » de Collabora Online

Le message de Collabora Online « Désolé, nous ne pouvons pas nous connecter à votre document » est un symptôme, et non un diagnostic. Il apparaît après le chargement de l'interface de l'éditeur, mais la session de document ne peut pas aboutir. Dans les configurations actuelles, la solution la plus rapide consiste à identifier la connexion défaillante dans le chemin WOPI plutôt que de modifier aléatoirement les paramètres de Collabora.

Ce guide s'appuie sur la documentation d'administration actuelle de Nextcloud 35 et sur les instructions du SDK Collabora Online 25.04. La même logique de dépannage s'applique à de nombreuses intégrations ownCloud et WOPI personnalisées, mais les noms exacts des paramètres peuvent varier selon la plateforme et la version.

Qu'est-ce qui provoque généralement cette erreur de connexion Collabora ?

Le bon fonctionnement d'une session de navigation dépend de plusieurs éléments. Le navigateur de l'utilisateur doit pouvoir accéder au serveur de stockage et à Collabora ; le serveur de stockage doit pouvoir accéder à Collabora ; Collabora doit pouvoir accéder au serveur de stockage ; les protocoles et les certificats doivent être compatibles ; et le proxy inverse doit rediriger correctement les requêtes HTTP et WebSocket de Collabora. La page de dépannage officielle de Nextcloud détaille ces exigences de connectivité bidirectionnelle.

Cela signifie qu'il n'existe pas de solution unique et universelle. Choisissez la méthode de réparation en fonction du premier test ayant échoué :

1. Vérifiez les points de terminaison de découverte et de fonctionnalités de Collabora

Commencez par l'URL publique de Collabora utilisée par votre intégration. Ouvrez ces points de terminaison dans un navigateur et depuis le serveur de stockage :

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

La documentation de dépannage actuelle de Nextcloud recommande d'effectuer les deux tests. Le point de terminaison de découverte doit renvoyer du XML, tandis que le point de terminaison des capacités renvoie les données de capacité Collabora. Un délai d'attente dépassé, un avertissement de certificat, une erreur 404, une page d'erreur personnalisée du proxy ou une boucle de redirection indiquent que vous devez résoudre les problèmes de réseau ou de proxy inverse avant de modifier les paramètres WOPI.

Vérifiez d'abord les URL publiques de découverte et de fonctionnalités de Collabora ; les deux doivent être accessibles via le même nom d'hôte utilisé par l'intégration.

Pour obtenir des conseils officiels sur les points de terminaison, consultez la section Dépannage de Nextcloud Office et le manuel du SDK Collabora Online 25.04 .

2. Testez les quatre directions du réseau, et pas seulement le navigateur.

Une erreur fréquente consiste à supposer que, parce que office.example.comCollabora s'ouvre dans un navigateur web, il peut également récupérer des fichiers depuis le serveur de stockage. Ce n'est pas garanti. Testez directement depuis les hôtes ou conteneurs :

# 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

Si le nom d'hôte public est résolu différemment au sein de Docker, Kubernetes ou d'un réseau privé, il convient de déterminer s'il est préférable de corriger le DNS interne, d'ajouter un mappage d'hôte approprié ou de router via le point de terminaison public. Le DNS interne est généralement plus propre à grande échelle ; une entrée dans le fichier hosts est rapide pour une petite installation statique, mais sa maintenance devient plus complexe.

Exécutez des tests d'accessibilité depuis les serveurs eux-mêmes, puis utilisez le journal Collabora pour distinguer une panne réseau d'une panne de confiance WOPI.

3. Corrigez le proxy inverse si les routes WebSockets ou Collabora sont manquantes.

Collabora n'est pas une application web statique classique. Son proxy inverse nécessite des routes pour les ressources du navigateur, la découverte/les fonctionnalités, le trafic de documents et les WebSockets. Dans le manuel du SDK de Collabora, l'exemple Nginx redirige /browserle chemin WebSocket et /hosting/discoveryle trafic associé ./hosting/capabilities/cool/.../ws/cool/lool

Pour la route WebSocket, le proxy doit conserver l'hôte et transmettre la mise à niveau HTTP. Voici un exemple simplifié de configuration Nginx :

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;
}

Ne copiez pas ce code aveuglément si votre méthode de terminaison TLS diffère. Collabora fournit des modèles distincts pour la terminaison TLS de bout en bout et la terminaison SSL. Si la terminaison TLS est effectuée au niveau de Nginx et que la connexion au serveur est HTTP, les paramètres SSL internes de Collabora doivent correspondre à cette architecture. L'utilisation systématique de HTTPS est plus simple à appréhender, tandis que la terminaison TLS au niveau du proxy réduit la gestion des certificats dans les conteneurs, mais introduit une contrainte de configuration supplémentaire.

Un proxy inverse correct doit transférer les routes HTTP de Collabora et préserver la mise à niveau WebSocket pour la session de document.

4. Vérifier la cohérence du protocole, du certificat et du nom d'hôte

La documentation de configuration actuelle d'Office pour Nextcloud indique que le serveur Collabora Online doit utiliser le même protocole que l'installation Nextcloud, HTTPS étant recommandé. En pratique, une configuration mixte HTTP/HTTPS peut entraîner le blocage de contenu, des redirections incorrectes ou des échecs de validation du certificat du serveur.

Vérifiez ces éléments ensemble :

• L'URL Collabora enregistrée sur votre plateforme de stockage est l'URL publique exacte à laquelle les utilisateurs accèdent.
• Le certificat présenté par ce nom d'hôte est valide pour ce nom d'hôte et est approuvé par le serveur de stockage.
• Collabora peut valider le certificat HTTPS du serveur de stockage.
• Votre proxy inverse transmet correctement l'hôte et le schéma d'origine.
• Il n'existe aucune redirection du nom d'hôte Collabora configuré vers un autre nom d'hôte que WOPI ne prévoit pas.

Un certificat auto-signé peut convenir en laboratoire si chaque composant est explicitement configuré pour lui faire confiance, mais cette facilité se fait au détriment de la portabilité et entraîne fréquemment des échecs lors de mises à jour ou de reconstructions de conteneurs ultérieures. En production, une chaîne de certificats publiquement approuvée ou approuvée par l'organisation est un choix plus sûr.

5. Corrigez les listes d'autorisation WOPI au lieu de les désactiver.

Si la découverte fonctionne et que les journaux Collabora affichent des messages tels que «Unauthorized WOPI host Aucun hôte WOPI acceptable ne correspond à la cible », le problème ne concerne plus la connectivité de base, mais la configuration de confiance. La documentation de dépannage officielle de Nextcloud indique spécifiquement aux administrateurs de consulter les journaux du conteneur dans ce cas.

Côté stockage, Nextcloud recommande de limiter les requêtes WOPI aux adresses IP des serveurs Collabora via la liste d'autorisation des requêtes WOPI . Côté Collabora, les hôtes de stockage WOPI autorisés doivent correspondre aux URL de stockage effectivement reçues par Collabora. Pour les domaines de stockage multiples, le SDK actuel de Collabora décrit les groupes d'alias WOPI.

Veillez à ce que l'URL du serveur Collabora et la liste blanche WOPI correspondent au déploiement réel ; utilisez des entrées de confiance restreintes plutôt que de désactiver la validation.

Consultez la configuration de Nextcloud Office pour connaître l'URL du serveur actuel et les instructions relatives à la liste blanche WOPI. Si vous utilisez ownCloud Infinite Scale, son service de collaboration utilise COLLABORATION_APP_ADDRl'URL de l'application bureautique et COLLABORATION_WOPI_SRCla source WOPI accessible depuis l'extérieur ; consultez la documentation du service de collaboration ownCloud .

Quand faut-il utiliser le code intégré plutôt qu'un serveur Collabora séparé ?

Pour une petite installation Nextcloud, le serveur CODE intégré réduit le nombre de composants gérés en externe. En contrepartie, il dépend toujours de la capacité de l'instance Nextcloud à s'accéder à elle-même via le nom d'hôte utilisé dans le navigateur. La documentation de dépannage de Nextcloud le mentionne explicitement et suggère de résoudre correctement ce nom d'hôte lorsque le serveur CODE intégré ne parvient pas à se connecter.

Un serveur Collabora distinct est généralement plus adapté lorsque vous avez besoin d'une mise à l'échelle indépendante, d'un service centralisé pour plusieurs instances de stockage ou d'une architecture de production avec des limites de ressources clairement définies. Il ajoute la configuration DNS, proxy, certificat, pare-feu et WOPI, ce qui augmente la charge opérationnelle.

Ce qu'il ne faut pas faire

• Ne désactivez pas la validation WOPI en premier lieu. Cela peut masquer l'incohérence réelle du nom d'hôte et affaiblir le périmètre de sécurité.
• N’exposez pas directement le port 9980 simplement parce que le proxy est défaillant. Corrigez le proxy, sauf si l’exposition directe fait partie intégrante d’une conception sécurisée et intentionnelle.
• Ne considérez pas qu'une réponse 200 de la page d'accueil de Collabora prouve que l'édition de documents fonctionne. La découverte, les fonctionnalités, l'accès aux fichiers WOPI et les WebSockets sont des processus distincts.
• Ne modifiez pas plusieurs couches simultanément. Testez après chaque modification afin de déterminer si la cause réelle réside dans le DNS, le TLS, le proxy ou la confiance WOPI.

Liste de vérification finale

Après avoir effectué une modification, vérifiez le système dans cet ordre :

1. Ouvrir /hosting/discoveryet /hosting/capabilitiesdepuis un navigateur.
2. Récupérez les mêmes points de terminaison depuis le serveur de stockage.
3. Depuis le serveur Collabora, récupérez l'URL d'état du serveur de stockage.
4. Ouvrez un document tout en consultant simultanément les journaux de Collabora et de stockage.
5. Vérifiez que le navigateur établit la connexion WebSocket Collabora sans déconnexions répétées.
6. Confirmez qu'un deuxième utilisateur peut ouvrir et modifier un document de test si une modification collaborative est requise.

Si les six vérifications réussissent, le message générique « C’est embarrassant » ne devrait plus masquer l’échec de connexion. Si le message persiste, veuillez capturer les lignes exactes du journal Collabora et l’erreur réseau du navigateur pour une tentative d’ouverture de document ; ces deux éléments sont plus utiles que le message générique de l’interface utilisateur.