WoPiX, un serveur WOPI libre, indépendant, simple et léger

35
28
avr.
2025
Bureautique

Un serveur WOPI (Web application Open Platform Interface) permet à un logiciel client de modifier un fichier stocké sur un serveur. C'est la couche indispensable pour qu'OnlyOffice, LibreOffice (Collabora Online) et d'autres suites bureautiques puissent être utilisés sur le web. Ainsi, lorsque vous réclamez l'ouverture d'un document depuis votre navigateur web, vous vous connectez à la suite bureautique en ligne avec une URL particulière, contenant, entre autres, le nom du fichier à ouvrir. La suite bureautique peut alors discuter avec le serveur WOPI pour récupérer le document. Les lectures, écritures et modifications d'un document sont gérées par le serveur WOPI, à la demande de la suite bureautique. Le protocole a été créé par Microsoft en 2012, la révision 14.5 de WOPI est sortie le 18 février 2025.

Les serveurs WOPI libres de Nextcloud, Seafile, Tracim… ne sont pas indépendants. Comme je voulais utiliser Collabora Online sans déployer un NextCloud complet, j'ai écrit un serveur WOPI très simple. Il est utilisé depuis plus d'un an sans problème et il est libre. Il est écrit en Java.

J'ai commencé ce développement car je travaille sur deux lieux privés différents avec un ordinateur à chaque endroit, un NAS dans l'un d'eux et je communique entre les deux machines à l'aide d'un dépôt git sur le NAS. Ça fonctionne relativement bien pour des fichiers qui n'ont pas vocation à rester ouverts dans des applications, mais pour des fichiers ODS ou ODT qui restent ouverts, c'est plus compliqué car je me retrouve souvent avec des versions concurrentes sur les deux machines. J'ai donc regardé du côté des suites de collaboration en ligne.

À une époque , je me servais d'Etherpad et de son équivalent tableur Ethercalc. Mais ces logiciels manquent de fonctionnalités, surtout le tableur. Problème supplémentaire : j'ai déjà beaucoup de fichiers aux formats LibreOffice.

Ça tombe bien, il y a la suite LibreOffice online, éditée par Collabora Online (CODE). Le problème — comme souligné par une dépêche — c'est qu'une fois CODE installé, tu te retrouves à poil avec rien qui marche : il faut un serveur utilisant le protocole WOPI.

Pour éviter d'installer tout un NextCloud, j'ai écrit un petit serveur WOPI. C'est du Java avec Spring Boot. Le serveur est très simple, sur le principe que plus un système est simple, moins il a de chances de tomber en panne.

Par exemple, il n'y pas de droits d'accès et on ne peut pas avoir plusieurs utilisateurs simultanés. Il faudrait mettre en œuvre le système de verrous et le système de droits d'accès (faire reposer les droits d'accès sur les droits du système de fichier, implique d'avoir un utilisateur sur la machine pour chaque utilisateur du logiciel). Cela n'a pas été implanté parce que je suis le seul utilisateur sur ma machine. Mais ce ne serait pas long à développer.

Le serveur une fois lancé expose des services REST, accessibles par la suite bureautique, mais aussi un service https qui permet d'afficher la liste des fichiers. Cette liste de fichier est cliquable et permet de se connecter à Libre Office avec la bonne URL. C'est la raison des paramètres proxyHost et code URL de l'application : être en mesure de générer la bonne URL.

Liste des fichiers

Le code est prévu pour avoir plusieurs backends à l'aide d'une interface. Le seul mis en œuvre pour l'instant c'est un stockage sur disque local (avec auto discovery : on lui donne un répertoire et il expose tout les documents du répertoire).

Il consomme peu de ressources, la charge dépendra plus de Collabora Online ou d'OnlyOffice. Le serveur WOPI se contente de lire un fichier à l'ouverture et de l'écrire de temps en temps (comme lors des enregistrements automatiques).

Il n'est pas testé avec OnlyOffice. En principe WOPI est une norme et ça devrait fonctionner.

On peut le lancer avec java -jar. C'est du Spring Boot. On pourrait utiliser systemd. De mon côté, je l'ai mis dans un container docker qui lance la commande suivante

java -Dlogging.level.root=INFO \
     -Dlogging.level.org.wopiserver=INFO \
     -Dserver.port=8880 \
     -jar /opt/app/app.jar \
     --baseDir /mnt/docs \
     --disableTLSCheck \
     --codeURL https://172.17.0.8:9980 \
     --proxyHost 192.168.124.252

Le code de WoPiX est dispo sur github et je suis ouvert à toute requête :-)

Aller plus loin

  • # Un autre serveur WOPI libre et indépendant

    Posté par  . Évalué à 10 (+8/-0).

    Ne sachant pas trop comment l'ajouter dans la dépêche, je l'avais prévu en commentaire : grâce à l'auteur de Tracim j'ai découvert un autre serveur WOPI indépendant, écrit en Python par la communauté CS3 (Cloud Storage Services for Synchronization and Sharing) (dont fait partie le CERN).

  • # Container docker

    Posté par  . Évalué à 1 (+2/-1).

    Hello LoloB, ça donne envie !
    Et je suis preneur du sujet Collobora + WoPIX

    Pense tu que tu pourrais créer un container Docker pour WoPIX qui permettrait un intégration avec le container Collabora :)

    • [^] # Re: Container docker

      Posté par  . Évalué à 3 (+2/-0).

      Bonjour cerede2000,

      j'utilise pour se faire une stack compose :

      version: "3.2"
      
      services:
        libreoffice:
          image: "collabora/code:latest"
          environment: 
            - username=admin
            - password=verysecretpass
          ports:
            - "9980:9980/tcp"
          network_mode: bridge
          links:
            - wopiserver
      
        wopiserver:
          image: "wopiserver:0.2"
          ports:
            - "8880:8880/tcp"
          volumes:
             - "/nas-pool/nasroot/backup/shared-document-lool:/mnt/docs"
             - "/var/lib/docker/laurent/libreoffice-online/etc:/etc/wopi"
             - "/var/lib/docker/laurent/libreoffice-online/opt:/opt/app"
          network_mode: bridge
      

      et le Dockerfile suivant pour le container WoPiX

      FROM eclipse-temurin:21
      RUN mkdir /opt/app
      CMD ["java", "-Dlogging.level.root=INFO", "-Dlogging.level.org.wopiserver=INFO", "-Dserver.port=8880", "-jar", "/opt/app/app.jar", "--baseDir", "/mnt/docs", "--disableTLSCheck", "--codeURL", "https://172.17.0.8:9980", "--proxyHost", "192.168.124.252"] 
      
      • [^] # Re: Container docker

        Posté par  . Évalué à 1 (+1/-0).

        Ah génial ! merci :)

        Encore un petit détail, pas de release dispo sur le Git ?

        Pour être honnête, je ne sais pas comment compiler le code pour obtenir un .jar :(

        Possible dans le Dockerfile ? Si je clone le git ?

        • [^] # Re: Container docker

          Posté par  . Évalué à 1 (+0/-0).

          Bonjour,

          je suis en déplacement là. Je pousse un jar début de semaine prochaine.

          Sinon un truc du genre ./gradlew bootJar devrait "faire the trick"

          Laurent

  • # Pour aller avec Karadav ?

    Posté par  . Évalué à 2 (+1/-0).

    Ah c'est sympa ! Ça pourrait peut-être fonctionner avec Karadav (https://github.com/kd2org/karadav) de Bohwaz ?

  • # WOPI

    Posté par  (site web personnel) . Évalué à 5 (+2/-0).

    Ce protocole WOPI m'intrigue. J'imagine que ça permet des choses plus fines que juste télécharger un fichier et envoyer une nouvelle version.

    Si ça permet de faire des modifications fines, comment cela est-il possible compte tenu de la diversité des formats dont on parle et de leurs fonctionnalités ?

    • [^] # Re: WOPI

      Posté par  . Évalué à 2 (+2/-2).

      Je pense que même pas. De ce que j’ai compris, c’est un protocole inventé par Microsoft, qui est une sorte de WebDAV avec gestion du verrouillage fichier, mais en propriétaire, c’est tout. Le verrouillage existe pourtant en standard dans WebDAV, même s’il n’est pas souvent implémenté. Bref, du réinventage de roue débile, mais à la sauce corporate. On est habitués.

      Si quelqu’un qui sait mieux peut me contredire, je n’en serais que plus satisfait, mais j’ai peu d’espoir.

      • [^] # Re: WOPI

        Posté par  . Évalué à 3 (+1/-0). Dernière modification le 30 avril 2025 à 11:17.

        Ça se vérifie rapidement. Je connais peu le sujet, mais en parcourant les protocoles, c'est assez clair: avec Webdav tu dois télécharger le fichier pour édition, pas avec WOPI. Pour une suite bureautique en ligne WebDAV ne convient donc pas.

        • [^] # Re: WOPI

          Posté par  (site web personnel) . Évalué à 3 (+0/-0).

          Ça télécharge quoi du coup ? Des bouts du fichier ?

          • [^] # Re: WOPI

            Posté par  . Évalué à 2 (+0/-0).

            WOPI ? WOPI ne télécharge rien vers ton poste, tout se passe sur le serveur. WOPI transmet le fichier au tableur sur le serveur, puis le tableur se charge de l'afficher au client dans le navigateur web.

            Microsoft a fait un petit schéma explicatif.

            • [^] # Re: WOPI

              Posté par  (site web personnel) . Évalué à 3 (+1/-1).

              Ça, c'est sans aucun intérêt technique par rapport au protocole WOPI. Que la suite bureautique qui utilise ce protocole pour télécharger le document tourne sur un serveur quelconque ou sur le poste de l'utilisateur, ça ne change strictement rien aux questions techniques sur ce protocole.

              Donc, je reformule, WOPI permet quoi au juste, au client qui l'implémente ? Le client étant en l'occurrence une suite bureautique – qui peut bien tourner sur un serveur et présenter son interface utilisateur sur le web, ou tourner sur un poste client et présenter son interface utilisateur avec Wayland, ça n'a aucune importance ici.

              Donc, j'imagine que WOPI doit au minimum permettre de télécharger un document bureautique. Faute de détails supplémentaires, on soupçonne pour le moment qu'il permet également d'en envoyer de nouvelles versions et de verrouiller des documents. Un genre de WebDAV à la sauce NIH Microsoft. Est-ce bien ça ou est-ce que ça a aussi des fonctionnalités spécifiquement liées à l'utilisation bureautique ?

              • [^] # Re: WOPI

                Posté par  . Évalué à 2 (+0/-0).

                En 2022 LeBouquetin et BohwaZ ont eu une bonne discussion à ce sujet. À l'époque, LeBouquetin avait implémenté les 2 dans Tracim, BohwaZ seulement WebDAV dans Karadav, depuis il a ajouté WOPI.

                • [^] # Re: WOPI

                  Posté par  . Évalué à 2 (+0/-0).

                  BohwaZ seulement WebDAV dans Karadav, depuis il a ajouté WOPI.

                  Rectification, il l'avait déjà ajouté.

                  LeBouquetin a un argument intéressant:

                  les deux protocoles ne sont pas comparables dans l'usage :

                  WebDav c'est accédé par les clients et donc il faut développer une robustesse à l'ensemble des clients qui exploitent le protocole. (…)
                  WOPI c'est utilisé pour interconnecter Collabora Online. C'est utilisé entre des briques serveur, c'est un environnement maîtrisé. (…)

                  (…) Si tu veux gagner de l'argent, fais un calcul de coût et de rentabilité.

                  Et un peu plus haut:

                  Est-ce que WOPI est mieux ? C'est pas vraiment ce que je pense. Ce que je pense, c'est que mettre du WebDAV entre les mains d'utilisateurs c'est du temps de support garanti.

              • [^] # Re: WOPI

                Posté par  . Évalué à 4 (+2/-0).

                est-ce que ça a aussi des fonctionnalités spécifiquement liées à l'utilisation bureautique ?

                Un paquet de fonctionnalités oui. L'une des moins triviales: l'édition à plusieurs ou coauthoring dans la doc. Ou la possibilité de mentionner un autre utilisateur (cf. Activity Object). Et tout plein de gestion de droits. Bref ça a l'air un poil plus complexe que Webdav : https://msopenspecs.microsoft.com/files/MS-WOPI/%5bMS-WOPI%5d.pdf

                • [^] # Re: WOPI

                  Posté par  (site web personnel) . Évalué à 3 (+0/-0).

                  Voilà, on commence à s'approcher de quelque chose de concret. Et ce que je ne comprends pas, c'est comment un truc pareil est possible sans une compréhension très fine du type de fichier manipulé, et sans y être très fortement lié.

                  Le cœur du sujet a l'air de figurer dans les méthodes ExecuteCellStorageRelativeRequest et ExecuteCellStorageRequest qui font malheureusement référence à une autre spec. Je vais essayer de creuser.

                  • [^] # Re: WOPI

                    Posté par  (site web personnel) . Évalué à 3 (+1/-1).

                    Bon, alors le protocole qui permet ces éditions multiples, c'est File Synchronization via SOAP over HTTP Protocol. Et en fait le cœur des opérations est plutôt défini dans Binary Requests for File Synchronization via SOAP Protocol.

                    C'est grosso modo un protocole de gestion de versions qui travaille sur des parties de fichier binaire. Et ça a l'air vachement compliqué. Chapeau à ceux qui ont réussi à implémenter tout ça, c'est sacrément touffu. Et savonneux évidemment (SOAPy, vous y êtes ?), pas étonnant de la part de MS.

                    Ce que je ne comprends pas, c'est comment ça peut fonctionner avec des fichiers bureautiques qui sont en fait des archives ZIP, et pour lesquels une édition partielle doit facilement pouvoir changer massivement le contenu binaire final. Peut-être que, dans les suites bureautique en ligne, les documents OpenDocument ou Office OpenXML sont en fait stockés non compressés, sous forme de répertoires.

                    Et accessoirement, ça me donne personnellement l'impression d'être une solution monstrueuse à un problème intrinsèque des formats bureautiques binaires. Parce que, comparé à l'édition partagée d'un fichier LaTeX dans un dépôt Git, c'est sûrement plus user-friendly, mais avec une complexité logicielle qui me semble héneaurme.

                    • [^] # Re: WOPI

                      Posté par  (site web personnel, Mastodon) . Évalué à 5 (+3/-0).

                      C'est pas compliqué : WOPI ne propose rien de plus que ce que sait déjà faire WebDAV. WOPI ne sert à rien (et bam).

                      99,99% (chiffre tiré de ma lecture du code de Collabora, OnlyOffice et NextCloud) des implémentations WOPI n'utilisent que 3 méthodes WOPI : GetFile (équivalent de HTTP GET), PutFile (même chose que HTTP PUT, sauf que ici c'est un POST, lol), et CheckFileInfo (idem que HTTP PROPFIND dans WebDAV, sauf que ça renvoie du JSON au lieu du XML).

                      Le reste n'est pas utilisé.

                      Alors comment ça marche l'édition collaborative avec WOPI ?

                      Bah c'est pas compliqué : Collabora/OO ont un serveur de document, qui charge (GetFile) le document et le garde en mémoire, partagé entre tous les clients qui font de l'édition collaborative. C'est eux qui gèrent tout la gestion des conflits etc. Ensuite régulièrement (intervalle, selon les modifs, ou selon si un utilisateur a fait Ctrl+S), ils envoient le document mis à jour (PutFile).

                      WOPI ne gère en rien l'aspect collaboratif. Il ne sert à rien pour ça. Peut-être en interne chez Microsoft, je sais pas, mais personne d'autre ne l'implémente.

                      On pourrait tout à fait remplacer WOPI par une URL HTTP en WebDAV et un token renvoyé dans le header Authorization. Ça ferait exactement la même chose, ça serait facile à faire, sans réinventer un protocole…

                      WOPI permet aussi de lock les fichiers, par exemple si tu veux être seul à éditer un document à la fois. Mais WebDAV gère déjà ça… Et seul OnlyOffice gère ça au niveau API, mais j'ai pas trouvé comment faire dans l'interface.

                      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

        • [^] # Re: WOPI

          Posté par  (site web personnel) . Évalué à 3 (+0/-0).

          Comment peut fonctionner une suite bureautique qui ne télécharge pas le fichier à ouvrir ? En téléchargeant des images de son rendu ?

          • [^] # Re: WOPI

            Posté par  . Évalué à 3 (+1/-0).

            C'est ton emploi du mot télécharge qui n'est pas clair. Ça donne l'impression qu'on télécharge sur le poste de l'utilisateur.

            • [^] # Re: WOPI

              Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

              Nope c'est le client (donc le serveur bureautique) qui télécharge le document.

              Après sur OnlyOffice, je crois que tu télécharge le document en entier sur ton poste effectivement car l'édition se fait dans le browser. Dans Collabora tu ne télécharge pas le document, tu as un websocket qui te renvoie l'image du document qui est édité sur le serveur (c'est un peu comme une transmission vidéo de l'édition du document, pour faire simple). L'approche Collabora permet de limiter l'édition/visualisation d'un document à certaines pages selon qui accède au document.

              « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.