Skip to main content
La sincronización con Dropbox usa tres partes de cada pod de Ayakaleaf Pro, y las tres solo arrancan con DROPBOX_ENABLED: "true":
  • web (el módulo dropbox): la vinculación, el diálogo de Dropbox del proyecto y el webhook al que llama Dropbox.
  • third-party-datastore: un servicio propio dentro del pod que procesa la cola de cambios que hay que enviar a Dropbox u obtener de él.
  • document-updater: con Dropbox activado, escribe en segundo plano los cambios del editor en MongoDB, unos minutos después de que todos hayan salido de un proyecto; solo entonces pasan a Dropbox.
Crea la aplicación de Dropbox y consulta cómo funciona la sincronización en Sincronización con Dropbox; esta página explica cómo trasladarlo a Kubernetes.

Configuración

1

ConfigMap

30-config.yaml (additions)
GIT_BRIDGE_ENABLED: "true" y el StatefulSet de git-bridge de Integración con Git deben estar en marcha: sin ellos, la configuración de la cuenta oculta la sección de sincronización de proyectos.
2

Secret

DROPBOX_TOKEN_CIPHER_PASSWORD cifra los tokens de Dropbox de los usuarios en MongoDB. Todas las réplicas deben usar el mismo valor, y cambiarlo más adelante obliga a todos los usuarios a volver a vincular Dropbox.
3

Crea los índices de la base de datos

Ejecuta una vez los comandos de índices de Crear los índices de la base de datos, en el primario del conjunto de réplicas:
4

Aplica y reinicia

third-party-datastore.log solo existe cuando DROPBOX_ENABLED es "true".
5

Abre el webhook a internet

Dropbox debe poder llegar a ${OVERLEAF_SITE_URL}/dropbox/webhook desde internet. Si tu ingress o balanceador de carga solo permite algunas rutas o redes desde el exterior, permite esta; es la única ruta a la que llama Dropbox. Compruébalo desde fuera del clúster:
Después, añade el webhook en la App Console de Dropbox como se describe en la página del Toolkit.

Varias réplicas

No hace falta nada más aparte de compartir DROPBOX_TOKEN_CIPHER_PASSWORD:
  • El webhook puede llegar a cualquier réplica. Solo pone el cambio en la cola en Redis.
  • Todas las réplicas ejecutan third-party-datastore, y cada una trabaja sobre la cola compartida. La cola de un usuario se toma con un bloqueo en Redis, de modo que solo una réplica envía u obtiene a la vez los cambios de un usuario determinado.
  • El document-updater de cada réplica escribe en segundo plano los proyectos inactivos. Cada proyecto se toma de una lista compartida en Redis, por lo que se escribe una sola vez.

Probado en Kubernetes

Contra una simulación de la API de Dropbox, en Kubernetes 1.37 con tres réplicas detrás de HAProxy, nuestras pruebas de extremo a extremo para la sincronización con Dropbox se superan (59 casos): vinculación y desvinculación; envío a Dropbox de proyectos, ediciones, archivos binarios, cambios de nombre, movimientos y eliminaciones, incluida una edición del editor que llega mediante la escritura en segundo plano después de cerrar el proyecto, sin compilar ni usar “sync now”; aplicación de los cambios hechos en Dropbox mediante el webhook (desafío de verificación y comprobación de firma), proyectos nuevos a partir de carpetas nuevas, carpetas de proyecto eliminadas; proyectos con el mismo nombre; el diálogo de Dropbox del editor y “sync now” con su límite de frecuencia; reintentos, límites de frecuencia y tiempos de espera de Dropbox; cuentas desvinculadas cuando Dropbox está lleno, rechaza el token o está suspendido; cuentas de Overleaf suspendidas; y la respuesta del webhook cuando third-party-datastore no está disponible.
Última modificación el 2 de noviembre de 2026