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.
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
- Article Wikipedia sur le protocole WOPI (53 clics)
- Code source du projet (55 clics)
# Un autre serveur WOPI libre et indépendant
Posté par orfenor . É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).
[^] # Re: Un autre serveur WOPI libre et indépendant
Posté par LoloB . Évalué à 3 (+2/-0).
Hello,
j'avais vu ce serveur, il est cité dans la dépêche précédente. Je n'ai pas réussi à générer une URL valide, ce qui m'a amené à écrire WoPiX.
# Container docker
Posté par cerede2000 . É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 LoloB . Évalué à 3 (+2/-0).
Bonjour cerede2000,
j'utilise pour se faire une stack compose :
et le Dockerfile suivant pour le container WoPiX
[^] # Re: Container docker
Posté par cerede2000 . É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 LoloB . É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 Beurt . Évalué à 2 (+1/-0).
Ah c'est sympa ! Ça pourrait peut-être fonctionner avec Karadav (https://github.com/kd2org/karadav) de Bohwaz ?
[^] # Re: Pour aller avec Karadav ?
Posté par LoloB . Évalué à 2 (+1/-0). Dernière modification le 28 avril 2025 à 21:21.
A priori oui, il faudrait implementer
DocumentService
comme un client WebDav au lieu d'utiliser le filesystem de l'OS.[^] # Re: Pour aller avec Karadav ?
Posté par orfenor . Évalué à 3 (+1/-0).
Il y a déjà un serveur WOPI dans Karadav.
https://github.com/kd2org/karadav/blob/main/lib/KD2/WebDAV/WOPI.php
[^] # Re: Pour aller avec Karadav ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Oui et dans Paheko aussi, et ça marche très bien :)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# WOPI
Posté par 🚲 Tanguy Ortolo (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 benoar . É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 orfenor . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-0).
Ça télécharge quoi du coup ? Des bouts du fichier ?
[^] # Re: WOPI
Posté par orfenor . É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 🚲 Tanguy Ortolo (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 orfenor . É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 orfenor . Évalué à 2 (+0/-0).
Rectification, il l'avait déjà ajouté.
LeBouquetin a un argument intéressant:
Et un peu plus haut:
[^] # Re: WOPI
Posté par Faya . Évalué à 4 (+2/-0).
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 🚲 Tanguy Ortolo (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
etExecuteCellStorageRequest
qui font malheureusement référence à une autre spec. Je vais essayer de creuser.[^] # Re: WOPI
Posté par 🚲 Tanguy Ortolo (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 BohwaZ (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 🚲 Tanguy Ortolo (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 orfenor . É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 BohwaZ (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.