bin/init --tls, NGINX_* і TLS_* в overleaf.rc) не має відповідника; про Toolkit див. TLS-проксі.
Що має робити проксі
- Пропускати WebSocket (
/socket.io). - Дозволяти запити тривалістю 10 хвилин (довгі компіляції) і тіла запитів розміром 50 МБ (завантаження) або
MAX_UPLOAD_SIZE. - Тримати тайм-аут простою keep-alive у бік подів нижче 65 секунд — тайм-ауту nginx у поді.
- Надсилати
X-Forwarded-ForіX-Forwarded-Proto: https. - З кількома репліками утримувати користувача на одній репліці, див. Горизонтальне масштабування.
ConfigMap
X-Forwarded-Proto: https з довіреної адреси Ayakaleaf Pro вважає, що запити надходять через HTTP, і не встановлює свою захищену cookie сесії: тоді вхід не вдається. Встановлюйте OVERLEAF_SECURE_COOKIE лише тоді, коли користувачі справді відкривають сайт через HTTPS; будь-яке значення вмикає його, навіть "false".
Приклад з HAProxy
Щоб завершувати HTTPS у DaemonSet HAProxy з розділу Горизонтальне масштабування, об’єднайте сертифікат і його ключ в один PEM-файл і помістіть його в Secret:80-haproxy.yaml:
80-haproxy.yaml (changes)
config-hash, щоб HAProxy перезапустився, потім задайте ConfigMap, як описано вище, і перезапустіть репліки.
Перенаправлення зберігає порт запиту: це підходить для балансувальника навантаження на портах 80 і 443, але на NodePort воно перенаправляє http://host:30081 на https://host:30081. Якщо перед кластером немає балансувальника навантаження, приберіть рядок перенаправлення й дайте користувачам адресу https://...:30443.
Перевірено на Kubernetes
На Kubernetes 1.37 з трьома репліками та HAProxy, що завершує HTTPS, як описано вище, зOVERLEAF_SITE_URL на https:// та OVERLEAF_SECURE_COOKIE: користувачі активували облікові записи через посилання https://, входили із cookie сесії з позначкою Secure, завантажували та компілювали проєкти з отриманням PDF, залишалися на своїй репліці, відкривали WebSocket редактора (wss), а також клонували та виконували push через Git по HTTPS. Запити http:// на NodePort перенаправлялися на https:// з тим самим портом, як описано вище.
