Skip to main content
La synchronisation Dropbox utilise trois composants de chaque pod Ayakaleaf Pro, et tous trois ne démarrent qu’avec DROPBOX_ENABLED: "true" :
  • web (le module dropbox) : la liaison, la boîte de dialogue Dropbox du projet, et le webhook appelé par Dropbox.
  • third-party-datastore : un service à part entière à l’intérieur du pod qui traite la file des modifications à envoyer vers Dropbox ou à récupérer depuis Dropbox.
  • document-updater : lorsque Dropbox est activé, il écrit en arrière-plan les modifications de l’éditeur dans MongoDB, quelques minutes après que tout le monde a quitté un projet ; ce n’est qu’alors qu’elles partent vers Dropbox.
Créez l’application Dropbox et découvrez le fonctionnement de la synchronisation dans Synchronisation Dropbox ; cette page explique comment l’intégrer dans Kubernetes.

Configuration

1

ConfigMap

30-config.yaml (additions)
GIT_BRIDGE_ENABLED: "true" et le StatefulSet git-bridge de l’intégration Git doivent être en place : sans eux, les paramètres du compte masquent la section de synchronisation des projets.
2

Secret

DROPBOX_TOKEN_CIPHER_PASSWORD chiffre les jetons Dropbox des utilisateurs dans MongoDB. Tous les réplicas doivent utiliser la même valeur, et la modifier ultérieurement oblige chaque utilisateur à lier à nouveau Dropbox.
3

Créer les index de base de données

Exécutez une seule fois les commandes d’index de Créer les index de base de données, sur le primaire du replica set :
4

Appliquer et redémarrer

third-party-datastore.log n’existe que lorsque DROPBOX_ENABLED vaut "true".
5

Ouvrir le webhook sur Internet

Dropbox doit pouvoir atteindre ${OVERLEAF_SITE_URL}/dropbox/webhook depuis Internet. Si votre ingress ou votre répartiteur de charge n’autorise que certains chemins ou réseaux depuis l’extérieur, autorisez celui-ci ; c’est le seul chemin appelé par Dropbox. Vérifiez-le depuis l’extérieur du cluster :
Ajoutez ensuite le webhook dans l’App Console de Dropbox comme décrit sur la page du Toolkit.

Plusieurs réplicas

Rien de plus que le DROPBOX_TOKEN_CIPHER_PASSWORD partagé :
  • Le webhook peut atteindre n’importe quel réplica. Il se contente de placer la modification dans la file de Redis.
  • Chaque réplica exécute third-party-datastore, et chacun traite la file partagée. La file d’un utilisateur est prise avec un verrou dans Redis, de sorte qu’un seul réplica à la fois envoie ou récupère les modifications d’un utilisateur donné.
  • Le document-updater de chaque réplica écrit en arrière-plan les projets inactifs. Chaque projet est pris dans une liste partagée dans Redis ; il n’est donc écrit qu’une seule fois.

Testé sur Kubernetes

Face à une simulation de l’API Dropbox, sur Kubernetes 1.37 avec trois réplicas derrière HAProxy, nos tests de bout en bout pour la synchronisation Dropbox réussissent (59 cas) : la liaison et la dissociation ; l’envoi vers Dropbox des projets, modifications, fichiers binaires, renommages, déplacements et suppressions, y compris une modification de l’éditeur arrivant par l’écriture en arrière-plan après la fermeture du projet, sans compilation ni « sync now » ; l’application des modifications faites dans Dropbox via le webhook (défi de vérification et contrôle de signature), les nouveaux projets issus de nouveaux dossiers, les dossiers de projet supprimés ; les projets portant le même nom ; la boîte de dialogue Dropbox de l’éditeur et « sync now » avec sa limite de débit ; les nouvelles tentatives, limites de débit et délais d’attente de Dropbox ; les comptes dissociés lorsque Dropbox est plein, refuse le jeton ou est suspendu ; les comptes Overleaf suspendus ; et la réponse du webhook lorsque third-party-datastore est arrêté.
Dernière modification le 2 novembre 2026